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Industrial Process Measurement and Control Sectional Committee. ETD 18 

1 

NATIONAL FOREWORD 

This Indian Standard (Part 6) which is identical with lEC 61508-6 : 2000 'Functional safety of 
electrical/electronic/programmable electronic safety-related systems — Part 6; Guidelines on the 
application of lEC 61508-2 and lEC 61508-3' issued by the International ElectrotechnicaJ Commission 
(lEC) was adopted by the Bureau of Indian Standards on the recommendation of the Industrial 
Process Measurement and Control Sectional Committee and approval of the Electrotechnical Division 
Council. ' 

The text of lEC Standard has been approved as suitable for publication as an Indian Standard without 
deviations. Certain conventions are, however, not ;)denticai to those used in Indian Standards. 
Attention is particularly drawn to the following: 

a) Wherever the words International Standard' appear referring to this standard, they should 
be read as Mndian Standard'. i 

b) Comma (,) has been used as a decimal marker, while in Indian Standards, the current 
practice is to use a point (.) as the decimal marker. 

In this adopted standard, reference appears to certain International Standards for which Indian 
Standards also exist. The corresponding Indian Standards, which are to be substituted in their 
respective places, are listed below along with their degree of equivalence for the editions indicated: 



International Standard 



Corresponding Indian Standard 



lEC 61508-1 : 1998 Functional safety IS/lEC 61508-1 : 1998 Functional safety of 

of electrical/electronic/programmable electrical/electronic/programmable electronic 

electronic safety-related systems — safety-relatqd systems: Part 1 General 

Part 1 : General requirements requirements 



lEC 61508-2 : 2000 Functional safety 
of electrical/electronic/programmable 
electronic safety-related systems — 
Part 2: Requirements for electrical/ 
electronic/programmable electronic 
safety-related systems 

lEC 61508-3 : 1998 Functional safety 
of electrical/electronic/programmable 
electronic safety-related systems — 
Part 3: Software requirements 

lEC 61508-4 : 1998 Functional safety 
of electrical/electronic/programmable' 
electronic safety-related systems — 
Part 4: Definitions and abbreviations 

lEC 61508-5 : 1998 Functional safety 
of electrical/electronic/programmable 
electronic safety-related systems — 
Part 5: Examples of methods for the 
determination of safety integrity levels ^ 



IS/lEC 61508-2 : 2000 Functional safety of 
electrical/electronic/programmable electronic 
safety-related systems: Part 2 Requirements 
for electrical/ electronic/ programmable 
electronic safety-related systems 

IS/lEC 61508-3 : 1998 Functional safety of 
electrical/electronic/programmable electronic 
safety-related systems: Part 3 Software 
requirements 

iS/lEC 61§p^4 : 1998 Functional safety of 
electrical/electronic/programmable electronic 
safety-related systems: Part 4 Definitions 
and abbreviations 

IS/lEC 61508-5 : 1998 Functional safety of 
electrical/electronic/programmable electronic 
safety-related systems: Part 5 Examples of 
methods for the determination of safety 
integrity levels 



Degree of 
Equivalence 

Identical 



do 



do 



do 



do 



IS/lEC 51508-6:2000 



International Standard 



lEC 61508-7 : 2000 Functional safety 
of electrical/electronic/programmable 
electronic safety-related systems — 
Part 7: Overview of techniques and 
measures 

ISO/IEC Guide 51 : 1990^> Guidelines 
for tiie inclusion of- safety aspects in 
standards 



Corresponding Indian Standard 

IS/lEC 61508-7 : 2000 Functional safety of 
electrical/electronic/ programmable electronic 
safety-related systems: Part 7 Overview of 
techniques and measures 



IS/ISO/IEC Guide 51 * : 2005 Safety aspects 
— Guidelines for their inclusion in standards 



Degree of 
Equivalence 

Identical 



Technically 
Equivalent 



The technical committee has reviewed the provisions of the Jollowing International Standard referred 
in this adopted standard and has decided that it is acceptable for use in conjunction with this 
standard: 



International Standard 
lEC Guide 104: 1997 



Title 

Guide to the drafting of safety standards, and the role of Committees with 
safety pilot functions and safety group functions 



Only the English language text of the International Standard has been retained while adopting it in this 
Indian Standard, and as such the page numbers given here are not the same as in the lEC Standard. 

For the purpose of deciding whether a particular requirement of this standard is complied with, the 
final value, observed or calculated, expressing the result of a test, shall be rounded off in accordance 
with IS 2 : 1960 *Rules for rounding off numerical values [revised)'. The number of significant places 
retained in the rounded off value should be the same as that of the specified value in this standard. 



^* Since revised in 2005, 
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INTRODUCTION 

Systems comprised of electrical and/or electronic components have been used for many years 
to perform safety functions in most application sectors. Computer-based systems (generically 
referred to as programmable electronic systems (PESs)) are being used in all application 
sectors to perform non-safety functions and, increasingly, to perform safety functions. If 
computer system technology is to be effectively and safely exploited, it is essential that those 
responsible for making decisions have sufficient guidance on the safety aspects on which to 
make those decisions. 

This International Standard sets out a generic approach for all safety iifecycle activities for 
systems comprised of electrical and/or electronic and/or programmable electronic components 
(electrical/ electronic/programmable electronic systems (E/E/PESs)) that are used to perform 
safety functions. This unified approach has been adopted in order that a rational and 
consistent technical policy be developed for all electrically based safety-related systems, A 
major objective is to facilitate the development of application sector standards. 

In most situations, safety is achieved by a number of protective systems which rely on many 
technologies (for example mechanical, hydraulic, pneumatic, electrical, electronic, 
programmable electronic). Any safety strategy must therefore consider not only all the 
elements within an individual system (for example sensors, controlling devices and actuators) 
but also all the safety-related systems making up the total combination of safety-related 
systems. Therefore, while this International Standard is concerned with electrical/ 
electronic/programmable electronic (E/E/PE) safety-related systems, it may also provide a 
framework within which safety-related systems based on other technologies may be 
considered. ' 

It is recognized that there is a great variety of E/E/PES applications in a variety of application 
sectors and covering a wide range of complexity, hazard and risk potentials. In any particular 
application, the exact prescription of safety measures is dependent on many factors specific 
to the application. This International Standard, by being generic, will ertabie such a 
prescription to be formulated in future application sector international standards. 

This International Standard 

- considers all relevant overall, E/E/PES and software safety Iifecycle phases (for example, 
from initial concept, through design, implementation, operation and maintenance to 
decommissioning) when E/E/PESs are used to perform safety functions; 

- has been conceived with a rapidly developing technology in mind; the framework is 
sufficiently robust and comprehensive to cater for future developments; 

- enables application sector international standards, dealing with safety-related E/E/PESs, 
to be developed; the development of application sector international standards, within the 
framework of this International Standard, should lead to a high level of consistency (for 
example, of underlying principles, terminology, etc.) both within application sectors and 
across application sectors; this wilt have both safety and economic benefits; 

" provides a method for the development of the safety requirements specification necessary 
to achieve the required functional safety for E/E/PE safety-related systems; 

- uses safety integrity levels for specifying the target level of safety Integrity for the safety 
functions to be implemented by the E/E/PE safety-related systems; 
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- adopts a risk-based approach for the determination of the safety integrity level 
requirements; 

- sets numerical target failure measures for E/E/PE safety-related systems which are linked 
to the safety integrity levels; 

- sets a lower limit on the target failure measures, in a dangerous mode of failure, that can 
be claimed for a single E/E/PE safety-related system; for E/E/PE safety-related systems 
operating in 

o a low demand mode of operation, the lower limit is set at an average probability of 
failure of 10"^ to perform its design function on demand, 

o a high demand or continuous mode of operation, the lower limit is set at a probability 
of a dangerous failure of 10"^ per hour; * 

NOTE A single E/E/PE safety-related system does not necessarily nnean.a single-channel architecture. 

- adopts ^/broad range of principles, techniques and measures to achieve functional safety 
for E/E/PE safety-felated systems, but does not rely on the concept of fail-safe, which may 
be of value when^the failure modes are well-defined and the level of complexity is 
relatively low - the' concept of fail-safe was considered inappropriate because of the full 
range of complexity of E/E/PE safety-related systems that are within the scope of the 
standard. 
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Indian Standard 

FUi^CTfONAL SAFETY, OF ELECTRfCAL/ 

ELECTRONJC/PROGRAMMABLE ELECTRONIC 

SAFETY^RELATED SYSTEMS 

PART 6 GU8DEUMES QH THE APPUCATIONS OF lEC 61508-2 A^SD lEC 61508-3 
1 Scope 

1.1 This part of lEC 61508 contains infornnation and guidelines on lEC 61508-2 and 
lEC 61508-3. 

- Annex A gives a brief overview of the requirements of lEC 61508-2 and lEC 61508-3 and 
sets out the functional steps in their application. 

- Annex B gives an example technique for calculating the probabilities of hardware failure 
and should be read in conjunction with 7,4.3 and annex C of lEC 61508-2 and annex D, 

- Annex C gives a worked example of calculating diagnostic coverage and should be read in 
conjunction with annex C of lEC 61508-2. 

- Annex D gives a methodology for quantifying the effect of hardware-related common 
cause failures on the probability of failure, 

- Annex E gives worked examples of the application of the software safety integrity tables 
specified in annex A of lEC 61508-3 for safety integrity levels 2 and 3, 

1.2 IEC'61508-1, lEC 61508-2, lEC 61508-3 and lEC 61508-4 are basic safety publications, 
although this status does not apply in the context of low complexity E/E/PE safety-related 
systems (see 3.4.4 of lEC 61508-4). As basic safety publications, they are intended for use by 
technical committees in the preparation of* standards in accordance with the principles 
contained in lEC Guide 104 and lEC/ISO Guide 51. lEC 61508 is also intended for use as a 
stand-alone standard. 

1.3 One of the responsibilities of a technical committee is. wherever applicable, to make use 
of basic safety publications in the preparation of its publications. In this context, the 
requirements, test methods or test conditions of this basic safety publication do not apply 
unless specifically referred to or included in the publications prepared by those technica/ 
committees. 

NOTE In the USA and Canada, until the proposed process sector implementation of lEC 61508 (i.e. lEC 61511) 
is published as an international standard, existing national process safety standards based on lEC 61508 (i.e. 
ANSI/ISA 384.01-1996) can be applied to the process sector instead of lEC 61508. 

1.4 Figure 1 shows the overall framework for parts 1 to 7 of this standard and indicates the 
role that lEC 61508-6 plays in the achievement of functional safety for E/E/PE safety-related 

systems. 
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2 Normative references 



The following normative documents contain provisions which, through reference in this text, 
constitute provisions of this part of lEC 61508. For dated references, subsequent 
amendments to, or revisions of, any of these publications do not apply. However, parties to 
agreements based on this part of lEC 61508 are encouraged to investigate the possibility of 
applying the most recent editions of the normative documents indicated below. For undated 
references, the latest edition of the normative document referred to applies. Members of ISO 
and lEC maintain registers of currently valid International Sta^ndards. 

lEC 61508 (all parts), Functional safety of efectrical/electronic/programmable electronic 
safety-related systems 

lEC Guide 104:1997, Guide to the drafting of safety standards and the role of committees with 
safety pilot functions and safety group functions 

lEC/ISO Guide 51:1990, Guidelines for the inclusion of safety aspects in standards 

3 Definitions and abbreviations 

For the purpose of this standard, the definitions and abbreviations given in lEG 61508-4 
apply. 
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Annex A 

(informative) 



Application of SEC 61508-2 and of DEC 61508^3 
A.1 General 

Machinery, process plant and other equipment may, in the case of malfunction (for example 
by failures of electro-mechanical, electronic and/or programmable electronic devices), present 
risks to people and the environment from hazardous events such as fires, explosions, 
radiation overdoses, machinery traps, etc. Failures can arise from either physical faults in the 
device (for example causing random hardware failures), or from systematic faults (for example 
human errors made in the specification and design of a system cause systematic failure under 
some particular combination of inputs), or from some environmental condition. 

lEC 61508-1 provides an overall framework based on a risk approach for the prevention 
and/or control of failures in electro-mechanical, electronic, or programmable electronic 
devices. 

The overall goal is to ensure that plant and equipment can be safely automated. A key 
objective of this standard is to prevent 

- fafrures of control systems triggering other events, which in turn could lead to danger (for 
example fire, release of toxic materials, repeat stroke of a machine, ate); and 

- undetected failures in protection systems (for example in an emergency shut-down 
system), making the systems unavailable when needed for a safety action. 

lEC 61508-1 requires that a hazard and risk analysis at the process/machine level is carried 
out to determine the amount of risk reduction necessary to meet the risk criteria for the 
application. Risk is based on the assessment of both the consequence (or severity) and the 
frequency (or probability) of the hazardous event. 

lEC 61508-1 further requires that the amount of risk reduction established by the risk analysis 
IS used to determine if one or more safety-related systems are required and what safety 
functions (each with a specified safety integrity 2)) they are needed for. 

lEC 61508-2 and lEC 61508-3 take the safety functions and safety integrity requirements 
Tp? R Ini^^^^n'^'Jl"^-' ^^'^Snated as a E/E/PE safety-related system, by the application of 
lEC 61508-1 and establish requirements for safety lifecycle activities which 

" sonwarefa^d^"^"^ '^"''"'^ *^^ specification, design and modification of the hardware and 

" ?ho p^P/S'pQ "^ !.°' P:^^^"**"9 ^"d/or controlling random hardware and systematic failures 
(the E/E/PES and software safety lifecycles 3)). 'ciimres 



equipment necessary ,0 carry out the required safmytSnteesTlonE^^^^^^^^ ''''"^' .""' '"<='"^^ ^" 

l£!^J:TfZZ:^::iX^^ll7^\^eSX^ '^^^'^- ^^'^'^ '"'^^^'^^ .evel . . .^e highest and safety 

^ecil°eZTuZT,tlZTen%:^^^^^^^^ ^ -^-^sion was made to order the 

(sometimes referred to as a^a?e 'rmodT However it Lstr^^^^^^^^^ 

provided a statement o, equivalence is ^iven ii, the safet ' Ian S^o S "SSl ^TctsllT "'' 
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lEC 61508-2 and lEC 61508-3 do not give guidance on which level of safety integrity is 
appropriate for a given required tolerable risk. This decision depends upon many factors, 
including the nature of the application, the extent to which other systenns carry out safety 
functions and social and economic factors (see lEC 61508-1 and lEC 61508-5). 

The requirements of lEC 61508-2 and lEC 61508-3 include 

- the application of measures and techniques 0, which are graded against the safety 
integrity level, for the avoidance of systematic failures 2) by preventative methods; and 

- the control of systematic failures (including software failures) and random hardware 
failures by design features such as fault detection, redundancy and architectural features 
(for example diversity). 

In lEC 61508-2, assurance that the safety integrity target has been satisfied for dangerous 
random hardware failures is based on 

~ hardware fault tolerance requirements (see tables 2 and 3 of lEC 61508-2); and 

- the diagnostic coverage and frequency of proof tests of subsystems and components, by 
' carrying out a reliability analysis using appropriate data. 

In both lEC 61508-2 and lEC 61508-3, assurance that the safety integrity target has been 
satisfied for systematic failures is gained by 

- the correct application of safety management procedures; 

- the use of competent staff; 

- the application of the specified safety iifecycle' activities, including the specified 
techniques and measures 3); and 

" an independent functional safety assessment 4). 

The overall goal is to ensure that remaining systematic faults, commensurate with the safety 
integrity level, do not cause a failure of the E/E/PE safety-related system. 

lEC 61508-2 has been developed to provide requirements for achieving safety integrity in the 
hardware 5) of the E/E/PE safety-related systems including sensors and final elements. 
Techniques and measures against both random hardware failures and systematic hardware 
failures are required. These involve an appropriate combination of'fault avoidance and failure 
control measures as indicated above. Where manual action is needed for functional safety, 
requirements are given for the operator interface. Also diagnostic test techniques- and 
measures, based on software and hardware (for example diversity), to detect random 
hardware failures are specified in lEC 61508-2. 



't) The required techniques and measures for each safety integrity level are shown in the tables in annexes A 
and B of lEC 61508-2 and lEC 61508^3. 

2) Systematic failures cannot usually be quantified. Causes include: specification and design faults in hardware 
and software: failure to take account of the environmer^ (for exampje temperature); and operation-related faults 
(for example poor interface). ' ' 

3) Alternative measures to those specified in the standard are acceptable provided justification is documented 
djiring safety planning (seexlause 8 of lEC 61508-1). i 

^) Independent assessment does not always imply third party assessment (seelclause 8 of lEC 61508-1). 

5) Including fixed built-in software or software/ equivalents (also called firmware), such as application-specific 
integrated circuits. / 

5 
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iEC 61508-3 has been developed to provide requirements for achieving safety integrity for the 
software - both embedded (including diagnostic fault detection services) and application 
software. IEC 61508-3 requires a combination of fault avoidance (quality assurance) and fault 
tolerance approaches (software architecture), as there is no known way to prove the absence 
of faults in reasonably complex • safety-related software, especially the absence of 
specification and design faults. IEC 61508-3 requires the adoption of such software 
engineering principles as: top down design; modularity; verification of each phase of the 
development lifecycle; verified software modules and software module libraries; and clear 
documentation to facilitate verification and validation. The different levels of software require 
different levels of assurance that these and related principles have been correctly applied. 

The developer of the software may or may not be separate from the organization developing 
the whole E/E/PES. In either case, close cooperation is needed, particularly in developing the 
architecture of the programmable electronics where trade-offs between hardware and 
software architectures need to be considered for their safety impact (see fioure 4 of IEC 
61508-2). j^ r V y 

A.2 Functional steps in the application of !EC 61508-2 

The functional steps in the application of IEC 61508-2 are shown in figures A 1 and A 2 The 
functional steps m the application of IEC 61508-3 are shown in figure A.3. 

Functional steps for IEC 61508-2 (see figures A.I and A.2) are as follows. 

a) Obtain the allocation of safety requirements (see IEC 61508^1). Update the safetv 
plannmg as appropriate during E/E/PES development. ^ 

b) Determine the requirements for E/E/PES safety, including the safety inteqritv reauirements for 
each safety function (see 7.2 of IEC 6150^-2). Allocate TequiremeLtSrrranTpl^^^^^^^^ 
software supplier and/or developer for the application of IEC 61508-3 ^ 

components having a common cause due to fn™mnL ^ •, ^- ^'^^^^ ""^^ ""^^"'^ ''■°'^ 'ai'ures of 

such failures couid^.ead to rhrghTthaS-e^xrecfedSSLl ^^'Z^:::';:^^^^^'- ''' ^"^'^"'^^ ''^ 

c) Start the phase of planning for E/E/PES safety validation (see 7.3 of IEC 61508-2) 

d) Specify the architecture (confiquration) for thp p/f/ppq i^^;^ ^ w . 

elements. Review with the softwaVi c^./nniif/H f ^ subsystem, sensors and final 
architecture and the safl^y impSons of' hf ^Hp'T. 'h". ^^^'"'"^^ ""^ ^°»^^^^ 
software (see figure 4 of lEC^Ts'oBirileratel?:^^^^^^^^ '^*"^^" *^^ hardware and 

'^ oi:Z rhis"^l^L?U':xSrj\rS;%:°; /^^ ^^^^^^ -^-V-related system, 
subsystem (componentfto bTus'd^o Ta^r/ot fhil fS^^^ ''' ^^*^-'-- ''- 

' '^^'^^PE^^^^^^^^^ (components) used in the 

following: ^ ' ^^""^ °^ *^® subsystems (components), determine the 

- the proof-test interval for failures which are not automatically revealed- 

- the mean time to restoration; 

- the diagnostic coverage (see annex C of IEC 61508-2); 
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- the probability of failure; and 

- the safe failure fraction (see annex C of lEC 61508-2). 

g) Determine the architectural constraints (see tables 2 and 3 of lEC 61508-2). 

h) Create a reliability model for each of the safety functions that the E/E/PE safety-related 
system is required to carry out. ^ retditju 

rp?I!nt'!^Jf m^f ^ ''?'^f '! ^ ^^^^^^a^'cal formula which shows the relationship between reliability and 
relevant parameters relating to equtpment and conditions of use. 

i) Calculate a reliability prediction for each safety function using an appropriate technique. 
Compare the result with the target failure measure determined in b) above and the 
requirements of tables 2 and 3 of lEC 61508-2 (see 7.4.3.1 of lEC 61508-2). If the 
predicted reliability does not meet the target failure measure and/or does not meet the 
requirements of tables 2 and 3 of lEC 61508-2, then change 

- , where possible, one or more of the subsystem parameters (go back to f) above); 
and/or 

- the hardware architecture (go back to d) above). 

NOTE A number of modelling m'ethods are available and the analyst should choose which is the most 
appropriate (see 7,4.3.2.2 note 9 of lEC 61508-2 for a list of some methods that could be used). 

j) Implement the design of the E/E/PE safety-related system. Select measures and 
techniques to control systematic hardware failures, failures caused by environmental 
influences and operational failures (see annex A of lEC 61508-2). 

k) Integrate the verified software (see lEC 61508-3) onto the target hardware (see 7.5 of 
lEC 61508-2 and annex B of lEC 61508-2) and, in parallel, develop the procedures for 
users and maintenance staff to follow when operating the system (see 7.6 of lEC 61508-2 
and annex B of lEC 61508-2). Include software aspects (see A. 3 f)). 

I) Together with the software developer (see 7.7 of lEC 61508-3), validate the E/E/PES (see 
7.7 of lEC 61508-2 and annex B of lEC 61508-2). 

m) Hand over^the hardware and results of the. E/E/PES safety validation to the system 
engineers for further integration into the overall system. 

n) If maintenance/modification of the E/E/PES is required during operational life then re- 
activate lEC 61508-2 as appropriate (see 7.8 of lEC 61508-2). 

A number of activities run acrosk the E/E/PES safety lifecycle. The^e include verification (see 
7.9 of lEC 61508-2) and functional safety assessment (see clause 8 of (EC 61508-1). 

In applying the above steps the E/E/PES safety techniques and measures appropriate to the 
required safety integrity level are selected. To aid in this selection, tables have been 
formulated ranking the various techniques/measures against the four safety integnty levels 
(see annex B of lEC 61508-2). Cross-referenced to the tables is an overview of each 
technique and measure with references to further sources of information (see annexes A and 
B of lEC 61508-7). 

Annex B provides one possible technique for calculating the probabilities of hardware failure 
for E/E/PE safety-related systems. 

NOTE in applying the above steps, alternative measures to ,^h«^%^Pf;=^'^^^^ ^'' "''''^^^^^' 

provided justification js documented during safety planning (see clause 8 of lEC 6150B-1}. 
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NOTE For PE systems, activities for software occur in parallel (see figure A. 3). 

Figure A.1 - Application of lEC 61508-2 
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NOTE For PE systems, activities for software occur in parallel (see figure A.3). 



Figure A.2 - Application of lEC 61508-2 (continued) 
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A.3 Functional steps in the application of lEC 61508-3 

Functional steps for lEC 61508-3 (see figure A.3) are as follows. 

a) Obtain the requirements for the E/E/PE safety-related systems and relevant parts of the 
safety planning (see 7.3 of lEC 61508-2). Update the safety planning as appropriate 
during software development. 

NOTE Earlier lifecycle phases have already 

- specified the required safety functions and their associated safety integrity levels (see 7.4 and 7.5 of 
lEC 61508-1); 

- allocated the safety functions to designated E/E/PE safety-related systems (see 7.6 of lEC 61508-1); and 

- allocated functions to software within each E/E/PE safety-related system (see 7.2 of lEC 61508-2). 

b) Determine the software architecture for all safety functions allocated to software (see 7.4 
of lEC 61508-3 and annex A of lEC 61508-3). 

c) Review with the E/E/PES supplier/developer the software and hardware architecture and 
the safety implications of the trade-offs between the software and hardware''(see figure 4 
of lEC 61508-2), Iterate if required. 

d) Start the planning for software safety verification and validation (see 7.3 and 7.9 of 
lEC 61508-3). 

e) Design, develop and verify/test the software according to the 

- software safety planning, 

' - software safety integrity level and 

- software safety lifecycle.. 

f) Complete the final software verification activity and integrate the verified software onto the 
target hardware (see 7.5 of lEC 61508-3), and in parallel develop the software aspects of 
the procedures for users and maintenance staff to follow when operating the system (see 
7.6 of lEC 61508-3, and A.2 k)). 

g) Together with the hardware developer (see 7.7 of lEC 61508-2), validate the software in 
the integrated E/E/PE safety-related systems (see 7.7 of lEC 61508-3). 

h) Hand over the results of the software safety validation to the system engineers for further 
integration into the overall system. 

i) If modification of the E/E/PES software is required during operational life then re-activate 
this lEC 61508-3 phase as appropriate (see 7.8^of lEC 6*1508-3). 

A number of activities run across the software safety lifecycle. These include verification (see 
7.9 of lEC 61508-3) and functional safety assessment (see clause 8 of lEC 61508-3). 

In applying the above steps, software safety techniques and measures appropriate to the 
required safety integrity are selected. To aid in this selection, tables have been formulated 
ranking the various techniques/measures against the four safety integrity levels (see annex A 
of lEC 61508-3). Cross-referenced to the tables is an overview of each technique and 
. measure with references to further sources of information (see annex C of lEC 61508-7), 

Worked examples in the application of the safety integrity tables are given in annex E and 
lEC 61508-7 includes a probabilistic approach to determining software safety integrity for pre- 
developed software (see annex D of lEC 61508-7), 

NOTE In applying the above steps, alternative measures to those specified in the standard are acceotphio 
provided justificatton is documented during safety planning (see clause 6 of lEC 61508 1). acceptable 
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(informative) 



Example teehgi5q;ie for evalyatSng pfrobabintles 
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B.1 General 



This annex provides one possible technique for calculating the probabilities of hardware 
failure for E/E/PE safety-related systems installed in accordance with lEC 61508-1, 
lEC 61508-2 and lEC 61508-3. The information provided is informative in nature and should 
not be interpreted ^s the only evaluation technique that might be used. It does, however, 
provide a relatively 'simple approach for assessing the capability of E/E/PE safety-related 
systems. 

NOTE 1 Other techniques are described for example in ANSI/ISA 384.01-1996, Application of safety instrumented 
systems for the process Industries. 

There are a number of techniques available for the analysis of hardware safety integrity for 
E/E/PE safety-related systems. Two of the more common techniques are reliability block 
diagrams (see C.6.5 of lEC 61508-7) and Markov models (see C.6.4 of lEC 61508^7). Both 
methods, if correctly applied, yield similar results, but in the case of complex programmable 
electronic subsystems (for example where multiple channel cross-voting and automatic testing 
are employed) there imay be some loss of accuracy when reliability block diagrams are used 
compared to Markov models. 

This loss of accuracy may not be significant in the context of the complete^ E/E/PE safety- 
related system and when the accuracy of the reliability data used in the analysis is taken into 
account. For example, field devices often predominate in the analysis of the hardware safety 
integrity for E/E/PE safety-related systems. Whether the loss of accuracy is significant can 
only be determined in the particular circumstances. In the case of complex programmable 
electronic subsystems, reliability block diagrams give results with more pessimistic hardware 
safety integrity values than Markov models (i.e. reliability biock diagrams give a higher 
probability of failure). This annex uses reliability block diagrams. 

Where a failure of the EUC control system places a demand on the E/E/PE safety-related 
system, then the probability of a hazardous event occurring also depends on the probability of 
failure of the EUC control system. In that situation it is necessary to consider the possibility of 
co-incident failure of components in the EUC control system and the E/E/PE safety-related 
system due to common cause failure mechanisms. The existence of such failures could lead 
to a higher than expected residual risk unless properly addressed. 

1 
The calculations are based on the'following assumptions; 

- the resulting avera'ge probability of failure on demand for the subsystem is less than 10-1, 
or the resultant probability of failure per hour for the subsystem is less than 10-5; 

- component failure rates are constant over the life of the system; 

- the sensor (input) subsystem comprises the actual sensor(s) and any other components 
and wiring, up to but not including the component(s^where the signals are first combined 
by voting or other processing (for example for two sensor channels, the configuration 
would be as shown in figure B.I); 
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the logic subsystem comprises the component(s) where the signals are first combined, 
and all other components up to and including where final signals) are presented to the 
final element subsystem; 

the final element (output) subsystem comprises all the components and wiring which 
process the final signal(s) from the logic subsystem including the final actuating 
component(s); 

the hardware failure rates used as inputs to the calculations and tables are for a single 
channel of the subsystem (for example, if 2oo3 sensors are used, the failure rate is for a 
single sensor and the effect of 2oo3 is calculated separately); 

the channels in a voted group all have the same failure rates and diagnostic coverage; 

the overall hardware failure, rate of a channel of the subsystem is the sum of the 
dangerous failure rate and safe failure rate for that channel, which are assumed to be 
equal; 

NOTE 2 This assumption affects the safe failure fraction (see annex C of I EC 61508-2). but the safe failure 
fraction does not affect the calculated values for probability of failure given in this annex. 

for each safety function, there is perfect proof testing and repair (i.e. all failures that 
remain undetected are detected by the proof test), but^ for the effects of a non-perfect 
proof test see B.2.5; 

the proof test interval is at least an order of magnitude greater than the diagnostic test 
interval; 

for each subsystem there is a single proof test interval and mean time to restoration; 

NOTE 3 The mean time to restoration is defined in 7.4.3.2.2, note 5 of lEC 61508-2 as including the time 

taken to detect a failure. In this annex, the single assumed value of mean time to restoration for both detected 
and undetected failures includes the diagnostic test interval but not the proof test interval. For undetected 
failures, the mean time to restoration used in the calculations should not include the diagnostic test-interval, 
but since the mean time to restoration is always added "to the proof test interval, which is at least an order of 
magnitude greater than the diagnostic test interval, the error is not significant. 

multiple repair teams are available to work on all known failures; 

the expected interval between demands is at least an order of magnitude greater than the 
mean time to restoration; 

for all subsystems operating in low demand mode of operation, and for 1oo2, 1oo2D and 
2oo3 voted groups operating in high demand or continuous mode of operation, the fraction 
of failures specified by the diagnostic coverage is both detected and repaired within the 
mean time to restoration used to determine hardware safety integrity requirements; 

EXAMPLE If a mean time to restoration of 8 h is assumed, this includes the diagnostic test interval which is 
typically less than 1 h, the remainder being the actual repair time. 

NOTE 4 For 1oo2, 1oo2D and 2oo3 voted groups, it is assumed that any repair is on-IJne. Configuring an 
E/E/PE safety-related system, so that on any detected fault the EUC is put into a safe state, improves the 
average probability of failure on demand. The degree of improvement depends on the diagnostic coverage. 

for 1oo1 and 2oo2 voted groups operating in high demand or continuous mode of 
operation, the E/E/PE safety-related system always achieves a safe state after detecting a 
dangerous fault; to achieve this, the expected interval between demands is at least an 
order of magnitude greater than the diagnostic test intervals, or the sum of the diagnostic 
test intervals and the time to achieve a safe state is less than the process safety time; 
NOTE 5 The process safety time is defined in 7.4.3.2.5 of lEC 61508-2 as the period of time between a 
failure occurring in the EUC or the EUC control system (with the potential to give rise to a hazardous event) 
and the occurrence of the hazardous event if the safety function is not performed. 
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- when a power supply failure removes power from a de-e.nergize-to-trip E/E/PE safety- 
related system and initiates a system trip to a safe state, the power supply does not affect 
the average probability of failure on demand of the E/E/PE safety-related system; if the 
system is energized to trip, or the power supply has failure modes that can cause unsafe 
operation of the E/E/PE safety-related system, the power supply should be included in the 
evaluation; 

- where the term channel is used, it is limited to only that part of the system under 
discussion, which is usually either the sensor, logic or final element subsystem; 

- the abbreviated terms are described in table B.1. 
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Figure B.I - Example configuration for two sensor channels 
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Table B.1 - Terms and their ranges used in this annex 

(applies to I00I, 1oo2, 2oo2, 1oo2D and 2oo3) 



1 Abbre- 
viation 


Term (units) 


Parameter ranges In tables B.2 to B.5 and 
B.10 to B.13 


7-, 


Proof-test interval (h) 


One month (730 h)' 
Three months (2 190 h)' 
Six months (4 380 h) 
One year (8 760 h) 
Two years (17 520 h)^ 
10 years (87 600 h)^ 


MTTR 


Mean time to restoration (hour) 


8h 


DC 


Diagnostic coverage (expressed as a fraction in the equations and as a 
percentage elsewhere) 


0% 
60% 
90% 
99 % 


fi 


The fraction of undetected failures that have a common cause 
(expressed as a fraction in the equations and as a percentage 
elsewhere) (tables B.2 to B.5 and B.1C to B.13 assume ^= 2 x j3d) 


2 % 
10% 

20% 


h 


Of those failures that are detected by the dtagnoslic tests, the fraction 
that have a common cause (expressed as a fraction in the equations and 
as a percentage elsewhere) 
(tables 8.2 to 8.5 and B.10 to B,13 assume p = 2 x po) 


1 % 
5% 
10% 


A 


Failure rate (per hour) of a channel in a subsystem - 


0.1 X lO"' 
0,5 X 10'^ 
1 X 10-" 
5x10-^ 
10 X 10-^ 
50 X 10*' 


PFt)G 


Average probability of failure on demand for the group of voted channels 
(If the sensor, logic or ffnal element subsystem comprises of only one 
voted group, then PFDc is equivalent to PFDs, PFDi or PFDfb 
respectively) 




PFDs 


Average probability of failure on demand for the sensor subsystem 




PFDi 


Average probability of failure on demand for the logic subsystem 




PFDfE 


Average probability of failure on demand for the final element subsystem 




PFDsYs 


Average probability of failure on demand of a safety function for the 
E/e/PE safety-related system 




PFHg 


Probability of failure per hour for the group of voted channels 

(if the sensor, logic or final element subsystem comprises of only one 

voted group, then PFHg is equivalent to PFHs. PFHl or PFHfe 

respectively) 




PFHs 


Probability of failure per hour for the sensor subsystem 




PFHi 


Probability of failure per hour for the logic subsystem 




PFHfE 


Probability of failure per hour for the final element subsystem 




PFHsYs 


Probability of failure per hour of a safety function for the E/E/PE safety- 
related system 




Ad 


Dangerous failure rate (per hour) of a channel in a subsystem, equal to 
0,5 X (assumes 50 % dangerous failures and 50 % safe failures) 




Add 


Detected dangerous failure rate (per hour) of a channel in a subsystem 
(this is the sum of all the detected dangerous failure rales within the 
channel of the subsystem) 




AoL' 


Undetected dangerous failure rate (per hour) of a channei in a 
subsystem (this is the sum of all the undetected dangerous failure rates 
within the channel of the subsystem) 




Aso 


Detected safe failure rate (per hour) of a channel in a subsystem 
(this is the sum of all the detected safe failure rales within the channel 
of the subsystem) 




tci 


Channel equivalent mean down lime (hour) Tor loot, 1oo2, "2002 and 
2oo3 architectures (this is the combined down time for all the 
components in the channel of the subsystem) 




tea 


Voted group equivalent mean down time (hour) for 1oo2 and 2oo3 
architectures (this is the combined down time for all Ihe channels in the 
voted group) 




tcii' 


Channel equivalent mean down time (hour) for 1oo2D architecture (this 
IS the combined down time for all the components in the channel of the 
subsystem) 




tcB 


Voted group eouivalent mean down time (hour) for 1oo2D architecture 
(this IS the combined down time lor all the channels in the voted group) 




Tz 


Interval between demands (h) 




High demand or coniinuous mode only, 
^ Low demand mode only. 
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B.2 Average probabilttv ®f fsiSwr© on demand 
(Her Bow demand mod© of o^eratiocn) 

B.2.1 Preeedure for calculations 

The average probability of failure on demand of a safety function for the E/E/PE safe^-related 
L^tpT s deSned by calculating and combining the average probability of failure on 
Sr^^nd for a t^ which'together provide the safety function. Since m this annex 

:She probability^ are small, this can be expressed by the following (see figure B.2): 

PFDsYs = PFDs + PFD, + PFD^:^ 

where 

- PFDsYs is the average probability of failure on demand of a safety function for the E/E/PE 
safety-related system; 

- PFDs is the average probability of failure on demand for the sensor subsystem; 

- PFDu is the average probability of failure on demand for the logic subsystem; and 

_ pfDfe is the average probability of failure on demand for the final element subsystem. 



Sensor subsystem 

(sensors and input 

interface) 



Logic subsystem 



Final element subsystem 

(output interface and 

finshglements) 



Figure B.2 - Subsystem structure » 

To determine the average probability of failure on demand for each o/ the subsystems, the 
following procedure should be adhered to for each subsystem in turn. 

a) Draw the block diagram showing the sensor subsystem (input) components, logic 
subsystem components or final element subsystem (output) components. For example, 
sensor subsystem components may be sensors, barriers, input conditioning circuits; logic 
subsystem components may be processors and scanning devices; and final element 
subsystem components may be output conditioning circuits, barriers and actuators. 
Represent each subsystem as one or more loot, 1oo2, 2oo2, 1oo2D or 2oo3 voted 
groups. 

b) Refer to the relevant table from tables B.2 to B.5 which are for six-month, one-year, two* 
year and 10-year proof-test intervals. These tables also assume an 8 h mean time to 
restoration for each failure once it has been revealed. 

c) For each voted group in the subsystem, select from the relevant table of tables B,2 to B.5 

- architecture (for example, 2oo3); 

- diagnostic coverage of each channel' (for example. 60 %); 

- the failure rate (per hour), A, of each channel (for example, 5.0E-06); ^ 
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- the common cause failure ^-factors, p and j3d, for the interaction between the channels 
in the voted group (for example. 2 % and 1 % respectively). 

NOTE 1 It is assumed that every channel in the voted group has the same diagnostic coverage and failure 
rate (see B.1). 

NOTE 2 It is assumed in tables B.2 to B.5 (and in tables B.10 to B.13) that the J9-factor in the absence of 
diagnostic tests (also used for undetected dangerous failures in the presence of diagnostic tests), fi, is 2 times 
the ^factor for failure^ detected by the diagnostic tests, Po- 

d) Obtain, from the relevant table from tables B.2 to B.5, the average probability of failure on 
demand for the voted group. 

e) If the safety function depends on more than one voted group of sensors or actuators, the 
combined average probability of failure on demand of the sensor or final element 
subsystem, PFDs or PFDpe, is given in the following equations, where PFDqj and PFDqj is 
the average probability of failure on demand for each voted group of sensors and final 
elements respectively: 

PFDs^YPFDa, 



PFD^-l^PFD, 



Gj 



B.2.2 Architectures for low demand mode of operation 

NOTE 1 This subclause should be read sequentially, since equations which are valid for several architectures are 
only stated where they are first used. 

NOTE 2 The equations are based on the assumptions listed in B.1 . 

B.2.2.1 tool 

This architecture consists of a single channel, where any dangerous failure leads to a failure 
of the safety function when a demand arises. 
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iagnostioe ; 



Figure B.3 - 1oo1 physical block diagram 
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Figure B.4 - I00I reliability bloek diagram 
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Rgures B.3 and B.4 contain ttie relevant block diagrams. The dangerous failure rate for the 
channel is given by 



^D ~ ^DU **■ ^DD "" 'Z 



Figure B.4 shows that the channel can be considered to comprise of two components, one 
with a dangerous failure rate Xqu resulting from undetected failures and the other with a 
dangerous failure rate Xdd resulting from detected failures. .It is possible to calculate ihe 
channel equivalent mean down time fca adding the individual down times from both 
components, td and tc2» in direct proportion • to each component's contribution to the 
probability oif failure of the channel: , . 



tcE- 



' DU 



(T. 



+ MTTR\ + - 



■MTTR 



For every architecture, the detected dangerous failure rate and the undetected dangerous 
failure rate are given by 

A^=f(l-DC);A„o=|DC 

For a channel with down time tcE resulting from dangerous failures 

~ ^otcE since X^tc^ « 1 
Hence, for a I00I architecture, the average probability of failure on demand is 
PFDa={Xau+X^^)tcs 



B.2.2.2 1oo2 

This architecture consists of two channels connected in parallel, such that either channel can 
process the safety function. Thus there would have to be a dangeroSs aitfin both char^nelS 
be ore- a safety function failed on demand. It is assumed that any diagnSic Sina wo!ld 
on y report the faults found and would not change any output si'teTo" ch^ngr he' o^ 



3 




; Diagnostics > 

' 'A' • 



Figure B.5 - 1oo2 physical block diagram 
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Figure B.6 - 1oo2 reliability block diagram 

Figures B.5 and B.6 contain the relevant block diagrams. The value of tcE is as given in 
B.2.2.1, but now it is necessary to also calculate the system equivalent down time tasf which 
is given by 



ioB-^l^^MTTR 



^ A 

+ 



""^ MTTR 



The average probability of failure on demand for the architecture is 

PFD^ = 2((1 - p^)Xoo + (1 - P)^Duf tcEtea + Pd^odMTTR + pxJ^ + MTTflJ 

B.2.2.3 2oo2 

This architecture consists of two channels connected in parallel so that both channels need to 
demand the safety function before it can take place. It is assumed that any diagnostic testing 
would only report the faults found ^nd would not change any output states or change the 
output voting. 
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Figure B.7 - 2oo2 physical block diagram 
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Figure B.8 - 2oo2 reliability block diagram 
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Fiaures B7 and B.8 contain the relevant block diagrams. The value of tcB is as given in 
B 2 2^ and the average probability of failure on demand for the architecture is 

B.2.2.4 1oo2D 

,T.hi-«fvnhiieati«».cnD.'5JsJfi- of. .two_ channels connected in parallel. Durinq normal operation, 
both channels need to demand the safety function before it can take place. In addition, if the 
diagnostic tests in either channel detect a fault then the output voting is adapted so that the 
overall output state then follows that given by the other channel. If the diagnostic tests find 
faults in both channels or a discrepancy that cannot be allocated to either channel, then the 
output goes to the safe state. In order to detect a discrepancy between the channels, either 
channel can determine the state of the other channel via a means independent of the other 
channel. 
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Figure B.9 - 1oo2D physical block diagram 
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Figure B.tO - loo^D reliability block diagram 
The detected safe failure rate for every channel is given by 



Figures B.9 and B.10 contain the relevant block diagrams. The values of the equivalent mean 
down times differ from those given for the other architectures in B.2.2 and hence are labelled 
/ce' and Ige^' Their values are given by 



tcE' = 



^duIy + MTTr]+{Xoo + ^?d)MTTR 



^DU "^ ^DD + ^SD 



tGE'=- 



7-1 



^Dul-^ + MTTR 



yi^DD + ^so)MTTR 



^DU + "-DO + ^SD 
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The average probability of failure on demand for the architecture is 



PFDa =2(1 -'P)Xou(i^ - P)^Du + (1 - PoKd + XsD)tcB'tGB'^pD^DDMrrR'^pXou{^+ mttr] 



B.2.a.5 20O3 

This architecture consists of three channels connected in parallel with a nnajority voting 
arrangement for the output signals, such that t^e output state is not changed if only one 
channel gives a different result which disagrees with the other two channels. 

It is assumed that any diagnostic testing would only report the faults found and would not 
change any output states or change the output vo,ting. 
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Figure B.11 - 2oo3 physical block diagram 
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Figure B.I 2 - 2oo3 reliability block diagram 

Rqures B 11 and B.12 contain the relevant block diagrams. The value of Jcb is as given in 
B.2.2.1 and the value of taE is as given in B.2.2.2. The average probability of failure on 
demand for the architecture is 
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B.2.3 Detailed tables for Sow demand mode of operation 

Table B.2 - Average probability of faUure on demand for a proof test interval 
of six months and a mean time to restoration of 8 h 



Architecture 


DC 




X=1.0E-07 


f 


A=5.0E-07 


r A=1.0E-06 ! 


^ = 2% 
j3o=1% 


j3--,10% 

^0 = 5% 


^ = 20% 
Pd = 10% 


jS=:2% 

Po=1% 


J3 = 10% 

^0 = 5% 


^^20% 

^D=10% 


y5 = 2% 

^0=1% 


^=10% 

/?o = 5% 


^ = 20% 
J?o = 10% 


lool 

(see note 2) 


0% 


1.1E-04 


5.5E-04 


1.1E-03 


60% 


4.4E-05 


2.2E-04 


4.4E-04 


90% 


1.1E-05 


5-7E-05 - 


1.tE-04 , . 


99% 


1.5E-05 


7.5E-06 


1.5E-05 


1oo2 


0% 


2.2E-06 


1.^.E-05 


2.2E-05 


1.1E-05 


5.5E-05 


1.1E-04 


2.4E"05 


1.1E-04 


2.2E-04 


SO % 


8.8E-07 


4.4E-06 


8.8E-06 


4.5E-06 


2.2E-05 


4.4E-05 


9.1E-06 


4.4E-05 


B.8E-Q5 


90% 


2.2E-07 


1.1E-06 


2.2E-06 


ME-06 


5.6E-06 


1.1E-05 


2.3E-06 


1--1E-05 


2.2E-05- 


99% 


2.6E-08 


1.3E-07 


2.6E-07 


1.3f--07 


6.5E-07 


1.3E-06 


2.6E-07 


1.3E-06 


2.6E-06 


2oo2 

(see note 2) . 


0% 


2.2E-04 


1.1E-C3 


2.2E-03 


60% 


8.8E-05 


4.4E-04 


8.8E-04 


90 % 


2,3E-05 1,1E-04 


2,3E-04 


99% 


3.0E-06 ' 1.5E-05 


3.0E-05 


1oo2D 


0% 


2.2E-06 


1.1E-05 


2.2E-05 1.1E-05 


5.5E-05 


1.1E-04 


2.4E-05 


1.1E-04 


2.2E-04 


60% 


8.8E-07 


4.4E-06 


8.8E-06 4.4F-06 


2.2E-05 


4:4E-05 


8.9E-06 


4.4E-05 


8.8E-05 


90% 


2.2E-07 


1.1E-06 


2,2E-06 1-1E-06 


5.6E-06 


1.1E-05 


2.2E-06 


1JE-05 


2.2E-05 


99% 


2.6E-08 


1.3E-07 


2.6E-07 


1.3E-07 


6.5E-07 


1.3E-06 


2.6E-07 


1.3E-06 


2.6E-06 


2oc3 


0% 


2.2E-06 


1.1E-05 


2.2E-05 


1.2E-05 


^"5.6E-05 


1.1E-04 


2.7E-05 


1.1E-04 


2.2E-04 


^^60% 


8.9E-07 


4.4E-06 


8.8E-06 


4-6E-06 


2.2E-05 


4,4E-05 


9.6E-06 


4.5E-05 


B.9E-05 


90% 


2.2E-07 


1.1E-06 


2.2E-06 


1.1E-06 


5,6E-06 


1.1E-05 


2.3E-06 


1.1E-05 


2.2E-05 


99% 


2.6E-08 


1.3E-07 


2.6E-07 


1.3E-07 


6.5E-07 


1-3E-06 


2.6E-07 


1.3E-06 


2.6E-06 


NOTE 1^ This table gives example values of PFDg, calculated using the equations in B.2.2 and depending on the 
assumptions listed in B.1. If the sensor, logic or final eiement subsystem comprises of only one group of voted channels, 
then PFDg is equivalent to PFDs, PFDi or PFDfb respectively (see B.2. 1 ). 

NOTE 2 The table assumes j3 = 2 x j3d. For 1oo1 and 2oo2 architectures, the values of j3 and fio do not affect the 
average probability of failure. 



Table B.2 (continued) 
T 




NOTE 1 This table g:ves example values of PFDg, calculated using the equations in 8 22 and deoenriinn nn fha 
aTeSe^rSbSona^r ^ ^ ' ' ^"^ '" ''°' ^"' '°°' ^"=^''^'"^-' '^' ^'^^ °' P -«^ P^ do not affect the 
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Table B,3 - Average probability of failure on demand for a proof-test interval of one year 

and mean time to restoration of 8 ii 




NOTE 1 This table gives example values of PFDg, caicuiated using the equations in 3.2.2 and depending on the 
BssumiJiions'if^tet'm'bri/^'tnfeTs'Hnb^/rt^ru^'irTrdi^ifHnfw^^ only one group o'r voted cnanneis, 

then PFDg is equivalent to PFDs, PFDl or PFDfe respectively (see B.2.1 ). 

NOTE 2 The table assumes ^ = 2 x ft. For lool and 2co2 architectures, the values of p and fio do not affect the 
average probability of failure. 



Table B.3 (continued) 




NOTE 1 This table gives example values of PFDg, calculated using the equations in B.2.2 and depending on the 
assumptions listed in B.1. It the sensor, logic or final element subsystem comprises of only one group of voted channels, 
then PFDg is equivalent to PFDs, PFDl or PFD^. respectively (see B.2.1). 
NOTE 2 The table assumes i3 = 2 x ft. For tool and 2oo2 architectures, the values of j3 and ft do not affect the 
average probability of failure. 
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Table B.4 - Average probability of failure on demand for a proof-test interval 
of two years and a mean time to restoration of 8 h 



Architecture 


DC 


As1.0E"07 


A = 5:0E-07 


A=1.0E-06 1 


^=:2% 


j3d = 5% 


^=20% 
)3o=10% 


JS = 2% 


iS:=10% 

&=5% 


^ = 20% 
j5o=1C% 


! i3:=2% 
^0=1% 


i5=10% 

J5d=5% 


j5 = 20% 
&"10% 


I00I 

(see note 2) 


0%! 4.4E-04 


2.2E-03 


4.4E-03 


60»/J 1.8E-04 


8.8E-04 


1.8E-G3 


90% 4.4E-05 


2.2E-04 


4.4E-04 


99 % 4.8E-06 


2.4E-05 


4.8E-05 


1oo2 


0% 


9.0E-O6 


4.4E-05 


8.8E-05 


5.0E-05 


2.2E-04 


4.4E-04 


1.1E-04 


4.6E-04 


8.9E-04 


60% 


3.5E-06 


1.8E-05 


3.5E-05 


1.9E-05 


8.9E-05 


1.8E-04 


! 3.9E-05 


1.8E-04 


3.5E-04 


90% 


8.8E-07 


4.4E-06 


8,8E-06 


4.5E-06 


2.2E-05 


4.4E^05 


i 9.1E-06 


4.4E-05 


8.8E-05 


99% 


9.2E-08 


4.6E-07 


9.2E-07 


4.6E-07 


2.3E-06 


4.6E-06 


! 9.2E-07 1 


4.6E-06 


9.2E-06 


2oo2 

(see note 2) 


0% 


8.8E-04 


4.4E-03 


8,8E-03 


60% 


3.5E-04 


1.8E-03 


3.5E-03 


90% 


8.8E-05 


4.4E-04 


8.8E-04 


99 %| 


9.6E-06 - 


4.8E-05 


9.6E-05 J 


1oo2D 


0% 


9.0E-06 


4.4E-05 


B.8E-05 


5.0E-05 


2.2E-04 


4.4E-04 


1.1E-04 


4.6E-04 


8.9E-04 


60% 


3.5E-06 


1.8E-05 


3.5E-05 


1.8E-05 


8.8E-05 


1.8E-04 


3.6E-05 


1.8E-04 


3.5E-04 


90 %^ 8.8E-07 


4.4E-06 


8.8E-06 


4.4E-06 


2.2E-05 


4.4E-05 


8.8E-06 


4.4E-05 


8.8E-05 1 


99% 9.2E-08 


4.6E-07 


9.2E-07 


4.6E-07 


2.3E-06 


4.6E-06 


9.2E-07 


4.6E-06 


9.2E-06 


2oo3 


0%! 9.5E-06 


r4.4E-05 


8.8E-05 


6.2E-05 


2.3E-04 


4.5E-04 


1.6E-04 


5.0E-04 


9.3E-04 


60% 3.6E-06 


1.8E-05 


3.5E-05 


2.1E-b5 


9.0E-05 


1.8E-04 


4.7E-05 


1.9E-04 


3.6E-04 


90% 8.9E-07 


4.4E-06 


8.8E-06 


4.6F-06 


2.2E-05 


4,4E-05 


9.6E-06 


4.5E-05 


8.9E-05 


99% 9,2E-08 


4.6E-07 


9.2E-07 


4.6E-07 


2.3E-.06 


4.6E-06 


9.3E-07 


4.6E-06 


9.2E-06 


NOTE 1 This table gives example values of PFDa, calculated using the equations in B.2.2 and depending on the 
assumptions listed, in B.1 , !f the sensor, logic or final element subsystem comprises of only one group of voted channels, 
then PFDg is equivalent to PFDs, PFDl or PFDfe respectively (see 3.2.1 ). 

NOTE 2 The table assumes ^ ~ 2 x j3d. For I00I and 2oo2 architectures, the values of p and fio do not affect the 
1 average probability of failure. 



Table B.4 (continued) 




NOTE 1 This table gives example values of PFDg, calculated using the equations in B.2.2 and depending on the 

fu^^^^&!?^-® ^^^®^ '" ^'"'- '^ **^® ^®"^°^' '°9"^ °'' f-'^^' element subsystem comprises of only one group of voted channels 
then PFDg is equivalent to PFDs, PFDu or PFDfe respectively (see B.2.1). / y m 

S^ge%r2ab!% 0^^^^^^ ^ = 2 x ^.. For 1oo^ and 2oo2 architectures, the values of p and Po do not affect the 
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Table B.5 -- Average probability of failure on demand for a proof-test interval 
of 10 years and a mean tme to restoration of 8 h 



Architecture 


DC 


A=1.0E-07 


A=:5.0E-07 


A=1.0E-06 1 




p-z% 

^D=1% 


^^10% 
fc=S% 


J3=:20% 

j5d = 10% 


J3 = 2% 
j8d=1% 


J3 = 10% 

^0-5% 


J5=:20% 
^D=10% 


J8 = 2% 


^ = 10% 

&=5% 


J5=:20% 

pD^^o% 


lool 

(see note 2) 


0% 


2.2E-03 


1.1E-02 


2.2E-02 


60 % 8.8E-04 


4.4E-03 


8,8E-03 


90% 


2.2E-04 


1.1E-03 


2.2E-03 


99% 


( 2.2E-05 


1.1E-04 


2.2E-04 


1oo2 


0% 


5,0E-05 


2.2E'-04 


4.4E-04 


3.7E-04 1,2E-03" 


2.3E-03 


1.1E-03 


27E-03 


4,8E-03 


60% 1.9E-05 


8.9E-05 


1.8E-04 


1,1E-04 


4.6E-04 


9.0E-04 


2.7E-04 


9.6E-04 


1.8E-03 


90% 4,4E-06 


2.2E-05 


4.4E-05 


2.3E-05 


1.1E-04 


2.2E-04 


5.0"E"05 


2,2E-04 


4,4E-04 


99 % 4.4E-07 


2.2E-06 


4.4E-06 


2.2E-06 


1.1E-05 


2.2E-05 


4.5E-06 


2,2E-05 


4,4E-05 


2oo2 

(see note 2) 


0% 4.4E-03 


r 2.2E-02 


4.4E-02 


60% 


1.8E-03 
4.4E-04 




8.8E'03 


1,8E-02 


90% 




2.2E-03 


4,4E-03 


99% 


4.5E-05 


2.2E-04 


4.5E-04 


1002D 


0% 


5.aE-05 


2.2E-04 


4.4E-04 


^7E-04 


1.2E-03 


2.3E-03 


1.1E-03 


2.7E-03 


4.8E-03 


60% 


1.8E-05 


8.8E-05 


1.8E-04 


9.4E-05 


4.4E-04 


8.8E-04 


2.0E-04 


9.0E-04 


1.8E-03 


90% 


4.4E-06 


2,2E-05 


4.4E-05 


2.2E-05 


1.1E-04 


2.2E-04 


4.4E-05 


2,2E-04 


4.4E-04 


99% 


4.4E-07 


2.2E-06 


4.4E-06 


2-2E-06 


1.1E-05 


2.2E-05 


4.4E-06 


2,2E-05 


4-4E-05 


2oo3 


0% 


6.2E-05 


2.3E-04 


4.5E-04 


^ "6.8E-04 


1.5E-03 


2.5E-03 


2.3E-03 


3.7E-03 


5.6E-03 


60% 


2.1E-05 


9.0E-05 


1.8E-04 


1.6E-04 


5.0E-04 


9,3E-04 


4.7E-04 


1.1E-03 


2-0E--03 


90% 


4.6E-06 


2.2E-05 


4.4E-05 


2.7E-05 


1.1E-04 


2.2E-04 


6.3E-05 


2.4E-04 


4.5E-04 


99% 


4.4E-07 


2.2E-06 


4.4E-06 


2-3E-06 


1.1E-05 


2.2E-05 


4.6E-06 


2.2E-05 


4.4E-05 


NOTE 1 This table gives example values of PFDg, calculated using the equations in B.2.2 and depending on the 
assumptions listed in B.l. if the sensor, logic or final element subsystem comprises of only one group of voted channels, 
then PFDg is equivalent to PFDs, PFDl or PFDfe respectively (see B.2.1). 

NOTE 2 The table assumes p ~ 2 x Pp. For 1oo1 and 2oo2 architectures, the values of p and Po do not affect the 
average probability of failure. 



Table B.5 (continued) 



Architecture 


DC 


;i = 5.0E-06 


A=1.0E-05 


A=5.0E-05 1 




J3 = 2% 


)3 = 10% 
Pd-5% 


J3 =^ 20 % 

^0 = 10% 


^ = 2% 
Pd = 1 % 


j3-10% 
_fo=5%_ 


i5 = 20% 

iSD= 10% 


J3 = 2% 

)3d=:1% 


^ = 10% 
^0=5% 


J3 = 20% 

j»o=10% 


1oo1 

(see note 2) 


ro% 


>1E-01 


>1E-01 >1E-01 1 


60% 


4.4E-02 


8,8E-02 


>1E-01 


90% 


1.1E-02 


2.2E-02 


>1E-01 


99% 


t.1E-03- 


2.2E-03 


1.1E-02 


1oo2 


0% 


1.8E-02 


2.4E-02 


3,2E-02 


6.6E-02 


7.4E-02 


8.5E-02 


>1E-01 


>1E-01 


>1E-01 


60% 
90~% 


3.4E-03 


6.6E-03 


1-1E-02 


1.2E-02 


1.8E-02 


2.5E-02 


>1E-01 


>1E-01 


>1E-01 


3,8E-04 


1.2E-03 


2.3E-03 


1.1E-03 


2.8E-03 


4.9E-03 


1.8E-02 


2.5E-02 


3.5E-02 


99% 


2.4E-05 


l,1E-04 


2.2E-04 


5.1E-05 


2.3E-041 


4.5E-04 


r3.8E-04l 


1.3E-03 


2.3E-03 


2oo2 

(see note 2) 


0% 


>1E-01 


>1E-01 


>1E-01 


60% 


8,BE-02 


>1E-01 


>1E-01 


90% 


2.2E-02 


4.4E-02 


>1E-01 


99% 


2.2E-03 


4.5E-03 


2.2E-02 


1oo2D 


0% 


1,8E-02 


2.4E-02 


3.2E^02 


6.6E-02 


7.4E-02 


8.5E-02 


>1E-01 


>1E-01 


>1E-01 


60% 


1,5E-03 


4.9E-03 


9.2E-03 


4.2E-03 


1.1E-02 


1.9E-02 


7.1E-02 


9.9E-02 


>1E-01 


90 % 


2.3E-04 


1.1E-03 


2.2E'03 


4.7E-04 


2,2E-03 


4.4E-03 


3.0E-03 


1.2E-02 


2.3E-02 


99% 


2.2E-05 


1.1E-04 


2.2E-04 


4.4E-05 


2.2E-04 


4.4E^04 


2,2E-04 


1JE-03 


2.2E-03 


2oo3 


0% 


4,BE-02 


5.0E-02 


5.3E-02 


'>1E-01 


>1E-01 


[ >1E-01 


>1E-01 


>1E-01 


>1E-01 


60% 


8.3E-03 


T.1E-02 


1.4E-02 


3,2E-02 


3,5E-02 


4.0E-02 


>1E-01 


>1E-01 


>1E-01 


90% 


6.9E-04 


1.5E-03 


2.6E-03 


2.3E-03 


3.9E-03 


5.9E-03 


4.9E-02 


5.4E-02 


6.0E-02 


99% 


2.7E-05 


1.2E-04 


2.3E-04 


6.4E-05 


2.4E-04 


4.6E-Q4 


7.1E-04 


1.6E-03 


2.6E-03 


NOTE 1 This table gives exampie values of PFDc, calculated using the equations in B.2.2 and dependir 
assumptions listed in B.I. If the sensor, logic or final element subsystem comprises of only one group of voted 
then PFDg is equivalent to PFDs, PFDl or PFDfe respectively (see B,2.1 ). 

NOTE 2 The table assumes ^ = 2 x Po. For 1oo1 and 2oo2 architectures, the'vaiues of J3 and Pd do not 
average probability of failure. 


g on the 
channels. 

affect the 
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B.2.4 Example for low demand mode of operation 



Consider a safety function requiring a SIL2 system. Suppose that the initial 
the system architecture, based on previous practice, is for one group of 
pressure sensors, voting 2oo3. The logic subsystem is a redundant 1oo2D 
driving a single shut-down valve plus a single vent valve. Both the shut-down 
need to operate in order to achieve the safety function. The architecture is 
B.13. For the initial assessment, a proof-test period of one year is assumed. 



assessment for 
three analogue 
configured PES 
and vent valves 
shown in figure 



Sensor subsystem 



©- 



©- 



Electronic 
interface 



Electronic 
interface 



Electronic 
interface 



DC = 90 % 
Logique majorrtajre =; 2oo3 



rt 



Logic subsystem 




2003 




DC = 99 % 
Logique majorilaire = 1oo2D 



Final element 
subsystem 



Electronic 
interface 




Vent 
valve 



A = 5xi0-«h-i 

DC^ 60 % 

Voting = I00I 



Electronic 
interface 



— -I down I 
V valve J 



A=iOxia«h-i 

0C=: 60 % 

Votings I00I 



Figure B.13 - Architecture of an example for low demand mode of operation 



Table B.6 ^ Average probability of failure on demand for the sensor subsystem In the 
example for low demand mode of operation (one year proof-test interval and 8 h fWTTR) 
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Table B,7 - Average probability of failure on demand for the logic subsystem in the example 
for low demand mode of operation (one year proof-test interval and 8 h WSTTR) 



Architecture 


DC 


A=1.0E-05 1 




* P^2% 
& = 1% 


^=10% 

j?D=S% 


i5 = 20% 
&=10% 


1002D 


0% 


1,1E-03 


2.7E-03 


4.8E-03 


60% 


2.0E-04 


9.0E-04 


1.8E-03 


90% 


4.5E-05 


2.2E-04 


4.4E-04 


99'5iir4.8E-06 1 


2.4E-05 


4.BE-05 


NOTE This table is abstracted from table B.3. 



Table B.@ - Average probability of failure on demand for the final element subsystem 

in the example for low demand mode of operation 

(one year proof-test interval and 8 h MTTR) 



Architecture 


DC A = 5.0E-Q6 




A=:1.0E-05 




1oo1 


0% 1.1E-02 




2.2E-02 




60 %j 4.4E-03 


- : 


8.8E-03 




90% 


1.1E-03 




2,2E-03 




99% 


1.3E-04 




2.6E-04 




NOTE This table is abstracted from table B.3. | 



From tables B.6 to B.8 the following values are derived. 

For the sensor subsystem, 

PFDs = 2.3x10-4 

For the logic subsystem, 

PFDl = 4.8 X 10-6 

For the final element subsystem, 

PFDpE = 4,4x1 0-3 + 8,8x1 0-3 

1,3x10-2 

Therefore, for the safety function, 

PFDsYS = 2.3x10-4 + 4.8x1 0-6 + 1.3x10-2 

1.3x10-2 
H safety integrity level 1 
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To improve the system to meet safety integrity level 2, one of the following could be done: 

a) change the proof-test interval to six months 

1,1x10-4 

2,6x10-6 

2,2x10-3 + 4,4x10-3 
6,6x10-3 
6,7x10-3 
= safety integrity level 2 

b), change the 1oo1 shutdown valve (which is the output device with the lower reliability) to 
' 1oo2 (assuming p=^0% and jSo = 5 %) 



PFDs 
PFDl 
PFDfe 



PFD 



'SYS 



PFDs 
PFDl 
PFDfe 



PFD 



'SYS 



2.3 X 10-4 
4,8 X 10-6 

4.4 X 10-3 + 9,7x 10-4 
5,4 X 10-3 

5.6 X 10-3 

safety integrity level 2 



B.2. 



Effects of a non-perfect proof test 



Faults In th^ safety system that are not detected by either diagnostic tests or proof tests are 
foun^i only by an incidence of demand that requires the safety function "affected by the fault. 
Thus^ for these totally undetected faults, the expected demand rate on the safety system 
governs the 'e,ffective down time. 



An example of this is gjven beiovy f9r a 1oo2 architecture. Ta is the time between demands on 
the system: \ .-'; 



tcE=- 



^DU 



2.x r 



[ 2 J 2Ao 



fT 

'2 



+ MTTB 



-MTTR 



■tGe = 



"^DuiT, ,.,,^T-rt^V ^' 



DU 



2^0 13 ) 2Ao 



^ + MTTR h^:^ MTTR ' 
I 3\ jf Ao 



PFD^ = 2((1 - )3o)Aoo + (1 - p)l^^f tcetcE + lio^ooMTTf^ + ^■^f^+ MTTfl] + 



DU 



-^+mttr\ 



Table B.9 below gives the numeric results of a 1oo2 system with a 100 % one-year proof test 
compared against a 50 % proof test where the demand period Ta is assumed to be 10 years. 
This example has been calculated assuming a failure rate of 1x10*® per hour, a B value of 
10 % and a Po value of 5 %. 



IS/IEC 61508-6 : 2000 



Table B.D - Example for a non-perfect proof test 



Architecture 


DC 


A=1.0E-05 1 


100% proof test 


50 % proof test 
(T2 = 10 years) 


^=10% 


iS=10% 
& = 5% 


1oo2 


0% 


2.7E-03 


6.6E-02 


60% 


9.7E-04 


2.6E-02 


90% 


2.3E-04 


6.6E-03 


99% 


2.4E-05 


. 7.0E-04 



B.3 Probabiiity of faiSure per hour (for high demand or eontinuous mod© 
of operation) 

B.3.1 Procedure for calculations 

The method for calculating the probability of failure of a safety function for an E/E/PE safety- 
related system operating in high demand or continuous mode of operation is identical with 
that for calculating for a low demand mode of operation (see B.2.1). except that average 
probability of failure on demand {PFDsys) is replaced with probability of a dangerous failure 
per hour (PFHsys)* 

The overall probability of a dangerous failure of a safety function for the E/E/PE safety-related 
system. PFHsvSi 's determined by calculating the dangerous failure rates for all the sub- 
systems which together provide the safety function and adding together these individual 
values. Since in this annex the probabilities are small, this can be expressed by the following: 

PFHsYs = PFHs + PFH^^ + PFH,^ 

where 

- PFHsYs is the probability of failure per hour of a safety function for the E/E/PE safety- 
related system; 

„ PFHs is the probability of failure per hour for the sensor subsystem; 

- PFHi is the probability of failure per hour for the logic subsystem; and 

„ PFHpE is the probability of failure per hour for the final element subsystem. 

B,3-2 Architectures for high demand or continuous mode of operation 

NOTE 1 This subclause should be read sequentially, since equations which are valid for several architectures are 

only stated where they are first used. See also B.2.2. 

NOTE 2 The calculations are based on the assumptions listed in B.1. 

/ 
B.3.2.1 tool / ' 

Figures B.3 and B.4 s.how the relevant block diagrams. 



^D — ^DU *** ^DD - 2 



tcE=- 



^DU 



'''' +mttr\+^mttr 

Aq 



A, 
2 



^au-^{-^-DC)-lao=^DC 



m 
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If it is assumed tiiat the safety system puts the EUC into asafe state on detection of any 
failure, for a I00I architecture the following is obtained 

PFHq=Xqu 

B.3.2.2 1oo2 

Figure^ B.5 and B.6 show the relevant block diagrams. The value of tcE is as given in B.3.2.1 . 

PFHa^2({l-po)Xoo'^{'i-liKuftcE'^PD^DD'^P^Du 

e.3.2.3 2oo2 

Figures B.7 and B.8 show the relevant block diagrams. If it is assumed that each channeNs 
put into a safe state on detection of any fault, for a 2oo2 architecture the following is obtained 

PFHq = 2 A Qu 

B.3.2.4 I002O 

Figures B.9 and B.10 show the relevant block diagrams. 

* Aso=— DC 

^Du{j + MTTRy{Xoo + Xso)MTrR 

PFHa = 2(1 - ^)Aou((l - l3)2,ou + " Pd)^od + ^so)tcE'+pD^Do + P^ou 

B.3.2.5 2oo3 

Figures B.11 and B.12 show the relevant block diagrams. The value of tee is as given, in 
B.3.2.1. 



PFH^ = 6((1 - /Jo)Aoo + (1 - P]?^ouftcE + Pd^do + P^ 



DU 
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B.3.3 Detested tables for high demahd or eontimuous mode of operation 

Table B.10 - Probability of failure par hour (m high ^Qm^nd or eentinuous mode of 
operation) for a proof-test mtervaS of one month and a mean time to restoration of 8 h 




NOTE 1 This table gives exampie values of PFHq, calculated using the equations in B.3.2 and depending on the 
assumptions listed in B.1. If the sensor, logic or final element subsystem comprises of only one group of voted channels, 
then PFHg is equivalent to PFHs, PFHl or PFHfe respectively (see B.3.1 and B.2.1). 

NOTE 2 The table assumes P = 2 x Po. For 1oo1 and 2oo2 architecture^, the values of p and Po do not affect the 
average probability of failure. 











Table B.10 (cont 


Inued) 










Architecture 


DC 


A=5.0E-06 


A = 1.0E-05 


A = 5.0K-05 1 


^ = 2% 
i3o = 1% 


pr:W% 

Bo = 5 % 


^ = 20% 
Bo = 10% 


P^2% 

1^0=1% 


^=10% 

j8o = 5% 


^=20% 
j3d = 10% 


i5 = 2% 

j5o= 1 % 


j9=10% 

Pd'^5% 


J3=:20% 

&=10% 


1oo1 
(see note 2) 


0% 2.5E-06 


5.0E-06 


>1E-05 ■! 


60% 1.0E-06 


2.0E-06 


1.0E-05 ! 


90% 


2.5E-07 


5.0E-07 


2.5E-06 j 


99%! 


2.5E-08 


5.0F-08 


2.5E-07 


1oo2 


0%j 


5.4E-08 


"^SE-O? 


5.0E-07 


1.2E-07 


5.2E-07 


1.0E-06 


9.5E-07 


2.9E-06 


5.3E-06 


60 d 


3.7E-08 


1.8E-07 


3.5E-07 


7.7E-08 


3,6E-07 


7.1E-07 


5.4E-07 


1.9E-06 


3.6E-06 




90% 2.8E-08 


1.4E-07 


2.8E-07 


5.7E-08 


2.8E-07 


5.5E-07 


3.3E-07 


'!.4E-06 


2.8E-06 




99% 2.5E-08 


1.3E-07 


2,5E-07 


5.1E-08 


2,5E-07 


5.1E-07 


2.7E-07 


^3E-06 , 2.5E-06 1 


2oo2 

(see note 2) 


0% 5.0E-06 


1.0E-05 


>1E-05 




60% 2.0E-06 


■4.OE-O6 


>1E-05 


*■ 


90% 


5.0E-07 
5:0E-08 




l.OE-06 


5.0E-06 


S9% 




1.0E-07 


5.0E-07 


1002D 


0%* 5.4E-08 


2.5E-C7 


5.0E-07 


1.2E-07 


5.2E-07 


1.0E-06 


9.5E-07 


2.9E-06 


5.3E-06 


60 %| 


3.6E-08 


1.8E-07 


3.5E-07 


7.3H-08 


3.5E-07 


7.0E-07 


4.3E-07 


1.8E-06 


3.6E-06 


90% 


2.8F-08 


1.4E-07 


2.8E-07 


5.5E-08 , 


2.8E-07 


5.5E-07 


2.8E-07 


1,4E-06 


2.8E-06 


99% 


2.5E-08' 


1.3E-07 


2.5E-07 


5.1E-08 


2.6E-07 


5.1E-07 


2.5E-07 


1.3E-06 


2.5E-06 


2oo3 


0% 


6.3E-08 


2.6E-07 


5.1E-07 


1.5E-07 


5.5E-07 


1.0E-06 


1.8E-06 


3.6E-06 


5.9F-06 


60°/^ 


4.1E-08 


1 .8E-07 


3.5E-07 


9.2E-08 


3.7E-07 


7.2E-07 


9.1E-07 


2.2F.-06 


3.9E-06 


90% 


2.9E-08 


1.4E-07 


2.8E-07 6.2E-08 


2.8E-07 


5.6E-07 


4.4E-07 


1.5E-06 


2.9E-06 


99% 


2.6E-08 


1.3E-07 


2.5E-07 5.2E-08 


2.5E-07 


5.1E-07 


3.0E-07 


1.3E-06 


2,6E-06 


NOTE 1 Thij 
assumptions li 
then PFHg is e 

NOTE 2 The 
average proba 


5 table gives exampie values of PFHg. calculated using the equations in B.3.2 and depending on the 
sted in B.1 . If the sensor, logic or final element subsystem comprises of only one group of voted channe.s, 
quivalent to PFHs, PFHl or PFHfe respectively (see B.3.1 and B.2.1). 

table assumes p = 2 x pD^ For 1oo1 and 2oo2 architectures, the values of p and Pd do not affect the 
bilitv of failure. 
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Table B.t1 - Probabiiity of failure per hour (in high demand or continuous mode of 
operation) for a proof test interval of three months and a mean time 

to restoration of 8 h 



Architecture 


DC 


A=1.0E^07 1 A=5.0E-07 


A=1.0E-^6 1 


^=2% 

PD^^% 


^=10% 

po'S% 


J3 = 20% 
Po=10% 


J5=2% 
i3o=1 % 


^=10% 
^0 = 5% 


P=2Q% 
i3D = 10% 


i8 = 2% 

^0=1% 


JS=10% 

^£, = 5% 


j5=20% 

^£,= 10% 


I00I 

(see note 2) 


""0%^^ 


5.0E-08 


2.5E-07 


5.0E-07 


60% 


2.0E-08 


1.0E-07 


2.0E-07 


90% 


5.0E-09 


2.5E-08 


5.0E-08 


99% 


5-0E-10 


2.5E-09 


5.0E-09 


1oo2 


0% 


1.0E-09 


5.0E-09 


1.0E-08 


5.1E-G9 


2.5E-08 


5.0E-G8 


1.1E-08 


5.0E-08 


l.OE-07 


so% 


7,0E-10 


3.5E-09 


7,0E-09 


3.6E-09 


1.8E-08 


3.5E-C8 


7.2E-09 


3.5E-08 


7.0E-08 


90% 


5.5E-10 


2.8E-09 


5.5E-09 


2.8E-09 


1.4E-08 


2.8E-08 


5.6E-09 


2.8E-08 


5.5E-08 


99% 


5.1E-1C 


2.5E-09 


5.1E-09 


2.5E-09 


1.3E-08 


2.5E-08 


5,1E-09 


2 5E-08 


5.1E-08 


2oo2 

(see note 2) 


0% 
60% 


1.0E-07 


5.0E-07 


1.0E-06 


4.0E-08 


2,0E^07 


4.0E-07 


90% 


1.0E-08 


5.0E-08 


1.0E-07 . 1 


99% 


1.0E-09 


5.0E-09 


1.0E-08 


1002D 


0% 


1.0E-09 


5.0E-09 


1.0E-08 


5JE-09 


2.5E-08 


5.0E-08 


1.1E-08 


5.0E-08 


1.0E-07 


60% 


7.0E-10 


3.5E-09 


7.0E-09 


3.5E-09 


1.8E-08 


3.5E-08 


7.1E-09 


3.5E-08 


7.0E-08 


90% 


5.5E-1C 


2,8E-09 


5.5E-09 


2.8E-09 


1.4E-08 


2.8E-08 


5.5E-09 


2.8E-08 


5.5E-08 


99% 


5.1E-10 


2.5E-09 


5.1E-09 


2.5E-09 


1.3E-a8 


2.5E-08 


5,1E-09 


2.5E>08 


5.1E-08 


2oo3 


LP% 


1.0E-09 


5,0E-09 


1.0E-08 


5.4E-09 


2.5E-08 


5.0E-08 


1.2E-08 


5.1E-08 


1.0E-07 


IS0% 


7.1E-1C 


3.5E-09 


/,CE-09 


3.7E-09 


1.8E-08 


3.5E-08 


7.7E-09 


3.6E-08 


7.0E-08 


90% 


5.5E-10 


2,8E-09 


5.5E-09 


2.8E-09 


1.4E-08 


2.8E-08 


5.7E-09 


2.8E-08 


5.5E-0a 


99% 


5.1E-10 


2.5E-09 


5.1E-09 1 


2.5E-09 


1.3E-08 


2.5E-08 


5.1E-09 


2.5E-08 


5.1E-08 


NOTE 1 This table gives example values of PFHa, calculated using the equations in B.3.2 and depending on the 
assumptions listed in B.I. If the sensor, logic or final element subsystem comprises of only one group of voted channels, 
then PFHq is equivalent to PFHs, PFHl or PFHfe respectively (see B.3.1 and B.2.1). 

NOTE 2 The table assumes p = 2 x po. For loo", and 2oo2 architectures, the values of p and Po do not affect the 
average probability of failure. 











Table B. 11 (continued) 










Architecture 


DC 


A=^5.0E-05 


A=1.0E-05 


X = 5.0E-05 1 


^=2% 

PD=^^% 


p■^^o% 

^0=5% 


^=20% 

;8d = 10% 


p=2yo \p^^w% 
PD = ^%\ Pd = 5 % 


^=20% 

flo = 10% 


i3=^2% 
Pd= 1 % 


p=w% 

Pt>^S% 


^ = 20% 
&=10% 


I00I 

(see note 2) 


0% 


2.5E-06 


I 5.0E-06 


>1E-05 


60% 


1.0E-06 


2.0E-O6 


1.0E-05 


90% 


2.5E-07 


5.0E-07 


2.5E-06 


99% 


2.5E-08 


5.0E-08 


2.5E-07 


1oo2 


0% 


6.3E-08 


2.6E-07 ! 5.1E-07 


1.5E-07 


5.4E-07 


1.0E-06 


1.8E-06 


3.6E-06 


5.9E-06 


60% 


4,0E-08 


1.8E-07 


3,5E-07 


9.2E-08 


3.7E-07 


7.2E-07 


8.9E-07 


2.2E-06 


3.9E-06 


90% 


2.9E-08 


1.4E-07 


2.8E-07 


6.1E-08 


2.8E-07 


5.5E-07 


4.2E-07 


1.5E-06 


2,9E-06 


99% 


2.5E-08 


1,3E-C7 


2.5E-07 


5.1E-08 


2.5E-07 


5.1E-07 


2.8E-07 


1.3E-06 


2.5E-06 


2oo2 

(see note 2) 


0% 


5 OE-06 


1.0E-05 


>lE-05 


60% 


2.0E-'06 


4.0E-06 


>1E-05 


90% 


5.0E-07 


1.0E-06 


5.0E-Q6 


99% 


5.0E-08 1 l.OE-07 


5.0E-07 


1oo2D 


0% 


6,3E-08 


2.6E-07 


5.-1E-07 ■:,5E-07 


5.4E-07 


1.0E-06 


1.8E-06 


3.6E-06 


5.9E-06 


60% 


3.7E-08 


J.8E-07 


3.5E-07 7.9E-08 


3.6E-07 


7.1E-07 


5.7E-07 


1.9E-05 


3.7E-06 


90% 


2.8E-08 


1,4E-07 


2.8E-07 


5.6E:-08 


2.8E-07 


5.5E-07 


2.9E-07 


1.4E-06 


2.8E-06 


99% 


2.5E-08 


1.3E-07 


2,5E-07 


5.1E-0B 


2.5E-07 


5.1E-07 


2.5E-07 


1.3E-06 


2,5E-06 


2oo3 


0% 


9.0E-08 


2.8E-07 


.5.3E-07 2.6E-07 


6.3E-07 


ME-06 


4.5E-06 
2,0E-06 


5.9E-06 


7.6E-06 


60% 


5.1E-08 


1.9E.C7 


3.6E-07 1.4E-07 


4.1E-07 


7.5E-07 


3.2E-06 


4.7E-06 


90% 


3.2E-08 


1.4E-07 


2.8E-07 


7.2E-08 


2.9E-07 


5.6E-07 


7.1E-07 


1.8E-06 


3-1E-06 


99% 2.6E-C8 ! 


1.3E-C7 


2.5E-07 


6.3E-08 1 


2.6E-07 


5.1E-07 


3.2E-07 


1.3E-06 


2.6E-06 


NOTE 1 This table gives example values of PFHa, caicufated using the equations ir 
assumptions listed In B.1. If the sensor, logic or final element subsystem comprises of onl 
then PFHg is equivalent to PFHs, PFHl or PFHf£ respectively (see B.3.1 and 3.2.1). 

NOTE 2 The table assumes p ^ 2 x Po^ For I00I and 2oo2 architectures, the values 
average probability of failure. 
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Table B.12 - Probability of failure per hour (in high demand or continuous mode of 
operation) for a proof test interval of six months and a mean time to restoration of 8 h 



Architecture 


DC. 


A=1.0E-07 


A = 5.CE-07 


A=1.0E"06 - 1 


)5 = 2% 
Pd^1% 


j3=:10% 

Po=S% 


i5 = 20% 


^1=2% 
flo=1% 


J8 = 10% 

^£,= 5% 


J5=:20% 

^/j = 10% 


^^2% 

j3o=1% 


J3sl0% 
Por-.SVo 


^s20% 
/3d=10% 


loci 

(see note 2) 


0% 


S.OE-OS 1 2.5E-07 


5.0E-07 


60% 




2.0E-08 
5.0E-09 




1.0E-07 


' 2.0E-07 


30% 






' 2.5E-08 


5.0E-08 


99% 


5-0E-10 


2.5E-09 


5.0E-09 


1oo2 


0% 


1.0E-09 


5.0E-09 


1.0E-08 


5.3E-09 


2.5E-08 


5.0E-08 1.1E-08 


5.1E-d8 


1.0E-07 


60% 


7.0E-10 


3.5E-09 


7.0E-09 


3.6E-09 


1.8E-08 


3.5E-08 


7.4E-09 


3.5E-08 


7.0E-08 


90% 


^5H-10 


2.8E-09 


5.5E-09 


2.8E-09 


1.4E-08 


2.8E-08 


5.6E-09 


2.8E-08 


5.5E-08 


99% 


^1E-10 


2.5E-09 


5.1E-09 


2.5E-09 


1.3E-08 


2.5E-08 


5.1E-09 


2.5E-08 


5.1E-08 


2oo2 

(see note 2) 


0% 


1.0E-07 


5.0E-07 


1.0E-06 


60% 


4.0E-08 


2.0E-07 


4.0E-07 


90% 


1.0E-08 


5.0E-08 


1.0E-07 


99% 


1.0E-09 


5.0E-09 1.0E-08 | 


1oo2D 


0% 


1.0E-09 


5.0E-09 


1.0E-08 


5.3E-09 


2.5E-08 


5.0E-08 1.1E-08 


5.1E-08 


1.0E-07 


60% 


7.0E-10 


3.5E-09 


7.0H-09 


3.5E-09 


1.8E-08 


3.5E-08 7.2E-09 


3.5E-08 


7.0E-08 


90% 


5.5E-10 


2.8E-09 


5.5E-09 


2.8E-09 


1.4E-08 


2.8E-08 5.5E-09 


2.8E-08 


r5":5E-08 


99% 


5.1E-10 


2.5E-09 


5.1E-09 


2.5E-09 


1.3E-08 


2.5E-08 5.1E-09 


2.5E-08 


5.1E-08 ' 
1.0E-07 


2oo3 


0% 


1.0E-09 


5.0E-09 


1.0E-08 


5.8E-09 


2.6E-08 


5.1E-08 


1.3E-08 


5.3E-08 


60% 


7.1E-10 


3.5E-09 


7.0E-09 


3.8E-09 


1.8E-08 


3.5E-08 


8.3E-09 


3.6E-08 


7.1E-08 


90% 


5.5E-10 


2.8E-09 


5.5E-09 


2.8E-09 


1.4E-08 


2.8E-08 


5.8E-Q9 


2.8E-Q8 


S.SE-OS 


99% 


5.1E-10 


2.5E-09 


5.1E-09 


2.5E-09 


1.3E-08 


2.5E-08 5.1E-09 | 


2.5E-08 


5.1E-08 


NOTE 1 This table gives example values of PFHg, calculated using the equations in B.3.2 and depending on the 
assumptions listed in B.1. If the sensor, logic or final element subsystem comprises of only one group of voted channels, 
then PFHg is equivalent to PFHs, PF/-4 or PFHpe respectively (see B.3.1 and B.2.1). 

NOTE 2 The table assumes p = 2 x Po- For 1oo1 and 2oo2 architectures, the values of p and Po do not affect the 
average probability of failure. 











Table B,12 (continued) 










Architecture 


DC 


A=5.0E-06 


A=1.0E05 


A = 5.0E"05 ( 




j5 = 2% 
)9d=^1 % 


^ = 10% 

&^5% 


)5 = 20% 

^D=10% 


j3^2% 
j3o = 1% 


J5«10% 

Po^S% 


j5s20% 
&=10% 


J3 = 2% 

)3d=1% 


^=10% 

Pd^S% 


^ = 20% 
Po-10% 


1oo1 
(see note 2) 


0% 


2.5E-06 


5.0E-06 


>1E-05 


60% 


i.oE-oe 


2.0E-06 


1.0E-05 


90% 


2.5E-07 




5.0E-07 
5.0E-08 


2.5E-06 


99% 


2.5E-08 




1 2.6E-07 


1oo2 


0% 


7.6E-08 i 2.7E-07 


5.2E-07 


2."1E-07"1 


5,9E-07 


1.1E-06 


1 3.1E-06 


4.7E-06 


6.8E-06 


60% 


4.6E-08 


1.8E-07 


3,6E-07 
2.8E-07 


1.1E-07 


3.9E-07 


7.3E-07 


1.4E-06 


2.7E-06 


4.3E-06 


90% 


3.0E-08 


1,4E-07 


6,6E-08 


2.9E--07 


5.6E-07 


5.5E-07 
2,9E-07 


1.6E-06 


3.0E-06 


99% 


2,6E-08 


1.3E-07 


2.5E-07 


5.2E-08 


2.5E-07 


5.1E-07 


1.3E-06 


2.6E-06 


2oo2 

(see note 2) 


0% 


5.0E-(>6 


1.0E-05 


>1E-05 j 


60% 


2.0E-06 


4.0E-06 


>1E-05 f 


90% 
99% 


5.0E-07 


1.0E-06 




5.0E-06 
5.0E-07 




5.0E-08 


1.0F-07 








1oo2D 


0% 


7.6E-08 


2.7E-07 


5.2E-07 


2.1E-07 


5.9E-07 


LiE-oe"! 


rsliE-oe 

7.8E-07 


4.7E-06 


6.8E-06 


60% 


3.9E-08 


1.8E-07 


3.5E-07 


8.7E-08 


3.7E-07 


7.1E-07 


2.1E-06 


3.8E-06 


90% 


2.8E-08 


1.4F-07 


2.8E-07 


5-6E-08 


2.8E-07 


5.5E-07 


3.0E-07 


1.4E-06 


2,8E-06 
2.5E-06 


99% 


2.5E-C8 


1,3E-07 


2.5E-07 


5.1E-08 


2.5E-07 


5.1E-07 
1,2E-06 


, 2JE-07 


1.3E-06 


2oo3 


0% 


ri.3E-07 


3.2E-07 


5.5E-07 


4.2E-07 


7.7E-07 


8.4E-06 


9.2E-06 


1,0E-05 


60% 


6.7E-08 


2.0E-07 


3.7E-07 


2.0E-a7 


4.6E-07 


8.0E-07 


3.6E-06 


4.6E-06 


6.0E-06 


90% 


3.6E-08 


1.5E-07 


2.8E-07 


8.8E-08 


3-.1E-07 


5.8E-07 


1.1F-06 


2.1E-06 


3.4E-06 


99% 


2.6E-08 


1.3E-07 


2.5E-07 


5.5E-08 


2.6E-07 


5.1E-07J 


3.6E-07 


1.4E-06 


2,6E-06 


NOTE 1 This table gives example values of PFHg^ calculated using the equations in B.3.2 and depending on the 
assumptions listed in B.1 . If the sensor, logic or final element subsystem comprises of only one group of voted channels, 
then PFHg is equivalent to PFHs, PFHl or PFHpe respectively (see B.3.1 and B.2.1). 

NOTE 2 The table assumes p = 2x Po- For 1oo1 and 2oo2 architectures, the values of p and po do not affect the 

average probability of failure. 
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TabSe B.13 - Probability of failure per hour (in high demand or continuous mode of 
operation) for a proof-test interval of one year and a mean time to restoration of 8 H 




NOTE 1 This table gives example values of PFHg* calculated using the equations in B.3,2 and depending on the 
assumptions listed in B.1 . If the sensor, logic or final element subsystem comprises of only one group of voted channels, 
then PFHg is equivalent to PFHs, PFHl or PFHfb respectively (see B.3.1 and B.2.1). 

NOTE 2 The table assumes j3 - 2 x j3o. For 1oo1 and 2oo2.architectures, the values of p and Po do not affect the 

average probability of failure. 











Table B.13 (continued) 










Architecture 


DC 




;i = 5.0E-0€ 


i 


A = 1.0E-05 


A = 5.0E-05 1 


J5=:2% 
Po^^ % 


J5=:t0% 

Pd=5% 


j3 = 20 % 

pD = ^Q% 


P=2% 

^0=1 % 


^=10%ij3=:20% 

^0 = 5% Ji3D = 10% 


J3 = 2% 

^D = 1 % 


p^^o% 

Po~S% 


^=:20% 

j3d=1C% 


1oo1 

(see note 2) 


0% 


2.5E-06 


5.0E-06 


>1E-05 




60% 


1.0E-06 ■ 


2.0E-06 


1.0E-05 




90% 
99% 


2.5E-07 


5.0E-07 


2.5E-06 


2.5E-08 


5.0E-08 


2,5E-07 


1oo2 


0% 


1.0E-07 


2.9E-07 


5.4E-07 


3.1E-07 ! 6.8E-07 


1.1E-06 


5.8E-06 


6.9E-06 
3.7E-G6 


8.5E-06 ' 


60% 


5.6E-08 


1.9E^07 


3.7E-07 


1.6E-07 


4.3E-07 


7.7E-07 2.5E-06 


5.1E-06 


90% 


3.3F-08 


1.4E-07 


2.8E-07 


7.7E-08 


2.9E-07 


5.7E-07 
5JE-07 


8v2E-07 


1.9E-06 


3.2E-06 


99% 


2.6E-08 


1.3E-07 


2.5E-07 


5.3E-08 


2.5F-07 


3.2E-07 


1.3E-06 


2.6E-06 


2oo2 

(see note 2) 


0% 


5.0E-06 


1,0E-05 


>1E-05 




60% 


2.0E-06 


4.0E-06 


>1E-05 


90% 


5-0E-07 


1.0E-06 


5.0E-06 


99% 


5.0E-08 


1.0E-07 


5.0E-07 


1oo2D 


0% 


1.0E-07 


2.9E-07 


5.4E-07 


3.1E-07 


6.8E-07 ! 1.1E-06 


5.8E-06 


6.9E-06 


8..5E-06 


60% 


4.4E-08 


1,8E-C7 


3,6c-07 


1.0E-07 


3.8E-07 


r7.3E-07 


1.2E-06 


2.5E-06 


4.1E-06 


90% 


2.8E-08 


1.4E-07 


2.8E-07 


5.7E-08 


2.8E-07 


5.5E-07 


3,3E-07 


1,4E-06 


2.8E--06 


99% 


2.5E-08 


1.3E-07 


2.5E-07 


5.1E-08 


2.5E-07 


5.1E-07 


2.5E-07 


1.3E-06 


2.5E-06 


2oo3 


0% 


2.1E-07 


3-8E-07 


6,1E-07 


7.3E-07 


1.0E-06 


nL4E-6B 


>1E-05 


>1E-05 


>1E-05l 


60% 


9.9E-08J 


2.3E-07 


4.CE-07 


3.3E-07 


5.8E-07 


9.0E-07 


6.8E-06 


7.5E-06 


8.4E-06 


90% 


4.4E^08 


1.5E-07 2.9E-0y 


1.2E-07 


3.3E-07 


6.0E-07 


1.9E-06 


2.9E-06 


4.1E-06 


99% 


2.7E-08 


1.3E-07 1 2.5E-07 


5.8tf-08 


2.6E-07 5.1E-07 j 


4.4E-07 


1.4E-06 


2.7E-06 


NOTE 1 This table gives example values of PFHg, caiculated using the equations in B.3.2 and depending on the 
assumptions listed in B.1. If the sensor, logic or final element subsystem comprises of only one group of voted channels, 
then PFHg is equivalent to PFHs, PFHl or PFH^e respectlveiy (see B,3.1 and 6,2.-!). 

NOTE 2 The table assumes p ~ 2 x Po. For tool and 2oo2 architectures, the values of p and Pd do not affect the 
average probability of failure. 
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B.3.4 E:tample for high demand or continuous mode of operation 

Consider a safety function requiring a S1L2 system. Suppose tliat the initial assessment for 
the system architecture, based on previous practice, is for one group of two sensors, voting 
1oo2. The logic subsystem is a redundant 2oo3 configured PES driving a single shutdown 
contactor. This is shown in figure B.14. For the initial assessment, a proof-test period of six 
months is assumed. 



Sensor subsystem 



Electronic 
interface 



0- 



Electronic 
imerface 



Logic subsystem 



Final element 
subsystem 




Etectronic 
interface 




Contactor 



DC=0 % 
Voting = 1oo2 



-A= 10x10'' h"' 

pa= 1 % 

DC =99% 

Voting = 2oo3 



A=1x10**h"' 
DC=0% 

Voting = I00I 
See note 



NOTE The final element subsystem has an overall safe failure fraction greater than 60 %. 

Figure B.14 - Architecture of an example for high demand or continuous mode of operation 



Table B.14 - Probability of failure per hour for the sensor subsystem 

in the example for high demand or continuous mode of operation 

(six month proof-test interval and 8 h MTTR) 



Architecture 


DC 


;t = 5.0E-06 


^ = 2% 

Pd = ^ % 


J3 = 10% 

&=5% 


i3 = 20% 
^0=10% 


1oo2 


0% 


7.6E-08 


2.7E-07 


5.2E-07 


60% 


4.6E-08 


1.8E-07 


3.6E-07 


90% 


3.0E-08 


1,4E-07 


2.8E-Q7 


39% 


2.6E-08 


*1.3E-07 


2.5E-07 


NOTE This table is abstracted from table B.I 2. 1 
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Table B.I 5 - Probability of failure per hour for the logic subsystem in the example 
for high demand or continuous mode of operation (six month proof-test interval 

and 8 h iWTTR) 



Architecture 


~^C 


A=1.0E-05 1 


^ = 2% 
&=1% 


P = 10% 

&=s% 


J3=20% 
&=10% 


2000 


0% 


4.2E-07 


7.7E-07 


1.2E-06 


60% 


2.0E-07 


4.6E-07 


8.0E-07 


90% 


8.8E-08 


3.1E-07 


5.8E-07 


99% 


5.5E-08 


2.6E-07 


5.1E-07 


NOTE This table is abstracted from table B.12. | 



Table B.16 - Probability of failure per hour for the finai etement subsystem 

in the example for high demand or continuous mode of operation 

(six month proof-test interval and 8 h MTTR) 



Architecture 


DC 


A=1.0E.06 


1 


I00I 


0% 


'" 5.0E-07 


60% 


2,0E-07 


90% 


5,0E-08 


99% 


5.0E-09 


NOTE This table is abstracted from table B.12. 


j 



From tables B.14 to B.16 the following values are derived. 

For the sensor subsystem, 

PFHs = 5,2x10-^/h 
For the logic subsystem, 

PFHl = 5,5x10"Vh 

For the final element subsystem, 

PFHfe = 5,0x10"^/h 

Therefore, for the safety function, 

PFHsYs = 5,2 X 10'% 5,5 x 10"^ + 5,0 x 1 0"^ 

1,1x10"®/h 

s safety integrity level 1 
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1 

To improve the system to meet-safety integrity level 2, one of the following could be done: 

a) change the input sensor type and mounting to improve the defences against common 
cause failure, thus improving p from 20 % to 10 % and po from 10 % to 5 %; 

PFHs = 2.7x 10-7/h 

PFHi_ = 5,5 X 10-8/h 

PFHp^ = 5.0 X 10-7 /h 

PFHsYS = 8,3 X 1 0-7 / h 

s safety integrity level 2 

b) change the single output device to two devices in 1 oo2 (j3 := 1 % and j3d = 5 %). 



PFHs 


= 


5,2 X 10-7/ h 


PFHi^ 


= 


5,5 X 10-8 /h 


PFHfe 


^ 


5,1 X 10-8 /h 


PFHsYS 


:= 


6,3 X 10-7 /h . ■ . * 


• 


5 


safety integrity level 2 



B.4 References 

References [1] to [6] in the bibliography give further details on evaluating probabilities of 
failure. 
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(informative) 

CalculatEon of diagnostSe eoveirage and safe faUura firaetaon: 

worked example 



A method for calculating diagnostic coverage and safe failure fraction is given in annex C of 
lEC 61508-2. This annex briefly describes the use of this method to calculate the diagnostic 
coverage of an E/E/PE safety-related system. It is assumed that all of the information 
specified in lEC 61508-2 is available and has been used where required in obtaining the 
values shown in table C.I. Table C.2 gives limitations on diagnostic coverage that can be 
claimed for certain E/E/PE safety-related system components or subsystems. The values in 
table C.2 are based on engineering judgement. 

To understand all the values in table C.1, a detailed hardware schematic would be required, 
from which the effect of all failure modes could be determined. These values are only 
examples, for instance some components in table C.1 assume no diagnostic coverage 
because it is practically impossible to detect all failure modes of all components. 

Table C.1 has been derived as follows. 

a) A failure mode and effect analysis has been carried out to determine the effect of each 
failure mode for every component on the behaviour of the system without diagnostic tests. 
The fractions of the overall failure rate associated with each failure mode are shown for 
each component, divided between safe (S) and dangerous (D) failures. The division 
between safe and dangerous failures may be deterministic for simple components but is 
otherwise based on engineering judgement. For complex components, where a detailed 
analysis of each failure mode is npt possible, a division of failures into^SO % safe, 50 % 
dangerous is generally accepted. For this table, the failure modes given in reference a) 
have been used, although other divisions between failure modes are possible and may be 
preferable. 

b) The diagnostic coverage for each specific diagnostic test on each component is given (in 
the column labelled "DCcomp")* Specific diagnostic coverages are given for the detection of 
both safe and dangerous failures. Although open-circuit or short-circuit failures for simple 
components (for example resistors, capacitors and transistors) are shown to be detected 
with a specific diagnostic coverage of 100 %, the use of table C.2* has limited the 
diagnostic coverage with respect to item U16, a complex type B component, to 90 %. 

c) Columns (1) and (2) give the safe and dangerous failure rates, in the absence of 
diagnostic tests, for each component (As and Xqd + ^du respectively). 

d) We can consider a detected dangerous failure to be effectively a safe failure, so we now 
find the division between effectively safe failures (i.e. either detected safe, undetected 
safe or detected dangerous failures) and undetected dangerous failures. The effective 
safe failure rate is found by multiplying the dangerous failure rate by the specific 
diagnostic coverage for dangerous failures and adding the- result to the safe failure rate 
(see column (3)), Likewise, the undetected dangerous failure rate is found by subtracting 
the specific diagnostic coverage for dangerous failures from one and multiplying the result 
by the dangerous failure rate (see column (4)). 
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e) Column (5) giyes the detected safe failure rate and column (6) gives the detected 
dangerous failure rate, found by multiplying the specific diagnostic coverage by the safe 

■ and dangerous failure rates respectively, 

f) The table yields the following results: 

total safe failure rate X'^s "^Z^dd = 9»9 x 10-7 

(including detected dangerous failures) . 
total undetected dangerous failure rate ^^ou = S»"* ^ 10'® 

total failure rate ^A^ +J^^dd +2^^^/ = 1.0 x 10-6 

total undetected safe failure rate ^^su = 2,7 x 10-8 

diagnostic coverage for safe failures ■ ^'~"^=^ ^-W^ ^ ^^ ^^° 

diagnostic coverage for dangerous failures 

^ ^^ = -^ = 92 % (normally termed simply "diagnostic coverage") 

^nn^Y^nu 6,72 



^DD"^ jLj^OV 



E^s+E^DD 986 _„ 

safe failure fraction ^ ^ ^ , s^^r; — = occ ^ c-^o " ^^ ^° 

E^s+E^DD+E^Dti 365 + 672 

g) The division of the failure rate without diagnostic tests is 35 % safe failures, and 65 % 
dangerous failures. 
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Table C.1 - Example calculations for diagnostic coverage and safe failure fraction 



item 


No 


Type 


Division of safe and dangerous 


Division of safe and dangerous failures for | 








failures for each failure mode 


diagnostic coverage and calc 


ulated failure rates 










(X 


IQ-^) 




00 


SC 


Drift 


Function 


DCcomp 


(1) 


(2) 


(3) 


(4) 


(5) 


(6) 


S 


D 


S 


D 


S 


D 


S 


D 


S 


D 


As 


AoD+Aou 


As+Add 


Aou 


AsD 


Ado 


Print 




Print 


0.5 


0,5 


0.5 


0.5 














0,99 


0,99 


11.0 


11.0 


21.9 


0,1 


10.9 


10,9 


CN1 




Con96pin 


0.5 


0,5 


0,5 


0,5 










0,99 


0,99 


11.5 


11.5 


22,9 


0.1 


11,4 


11.4 


CI 




lOOnF 


1 





1 





' 











1 





3.2 


0.0 


3.2 


0.0 


3.2 


0.0 


C2 




10jiF 








1 

















1 





0.8 


0.0 


0.8 


0,0 


0.8 


0,0 


R4 




1(W 


0.5 


0.5 


0.5 


0.5 










1 


1 


1,7 


1,7 


3,3 


0.0 


1,7 


1.7 


Ft6 




100k 
























0,0 


0,0 


0,0 


0.0 


0.0 


0.0 


OSC1 




OSC24 MHz 


0.5 


0,5 


0,5 


0.5 


0,5 


0,5 


0.5 


0,5 


1 


1 


16,0 


16,0 


32,0 


0,0 


16.0 


16.0 


U8 




74HCT85 


0,5 


0.5 


0,5 


0,5 


0,5 


0,5 


0,5 


0,5 


0,99 


0,99 


22.8 


22,8 


45,4 


0.2 


22.6 


22.6 


U16 




MC68000-12 





1 





1 


0.5 


0,5 


0.5 


0.5 


0,90 


0.90 


260.4 


483.6 


695,6 


48,4 


234,4 


435.2 


U26 




74HCT74 


0,5 


0.5 


0,5 


0.5 


0,5 


0,5 


0,5 


0,5 


0.99 


0,99 


22,8 


22,8 


45,4 


0.2 


22.6 


22,6 


U27 




74F74 


0,5 


0,5 


0,5 


0,5 


0,5 


0,5 


0,5 


0.5 


0,99 


0,99 


14.4 


14.4 


28.7 


0,1 


14,3 


14.3 


U28 




PAL16L8A 





1 





1 





1 





1 


0,98 


0,98 


0.0 


88,0 


86,2 


1.8 


0,0 


86,2 


T1 




BC817 











0,67 





0,5 








1 


1 


0,0 


0.2 


0.4 


0.0 


0,0 


0,2 


-Total 


365 


672 


986 


50,9 


338 


621 


NOTE None of the failure modes of item R6 are detected, but a failure does not affect either safety or availability. j 


Key 






S. • Safe failure 






D Dangerous failure ^ 






OC Open circuit 






SC Short circuit 






Drift Change of value. 






Function Functional failures 






DCcomp Specific diagnostic coverage for the component 






See also table B.I. although in this table failure" rates are for the individual components in 


question rather than every ! 


component in a channel. 
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Table C.2 - Diagnostic coverage and effectiveness for different subsystems 



Component 


Low diagnostic 
coverage 


Medium diagnostic 
coverage 


High diagnostic 
coverage 


CPU (see note 3) 
register, Internal RAM 

coding and execution including flag register 
(see note 3) 

address calculation (see note 3) 
program counter, stack pornter 


total less than 70 % 
. 50% -70% ■ 
50 % - 60 % 
50 % - 70 % 
50 % - 60 % 
50 % - 70 % 
40 % - 60 % 


total less than 90 % 
85 % - 90 % 
75 % - 95 % 
85 % • 98 % 
60 % - 90 % 


99 % - 99,99 % 
85 % - 98 % 


Bus 

memory management unit 
bus-arbitration 


50% 
50% 


70% 
70% 


90 % - 99 % 
90 % - 99 % 


Interrupt handling 


40 % - 60 % 


60% -90% 


85 % - 98 % 


Clock (quartz) (see note 4) 


50% 


- 


95 % - 99 % 


Program flow monitoring 

temporal (see note 3) 

logical (see note 3) 

temporal and logical (see note 5) 


40 % - 60 % 
40 % - 60 % 


60 % - 80 % 
60 % - 90 % 
65 % - 90 % 


90 % - 98 % 


Invariable memory 


50 % - 70 % 


99% 


99,99 % 


Variable memory 


50 % - 70 % 


85 % - 90 % 


99 % - 99.99 % 


Discrete hardware 

digital I/O 
analogue I/O 
power supply 


70% 
50 % - 60 % 
50 % - 60 % 


90% 
70 % - 85 % 
70 % - 85 % 


99% 
99% 
99% 


Communication and mass storage 


90% 


99.9 % 


99.99 % 


Electromechanical devices 


90% 


99 % 


99,9 % 


Sensors 


50 % - 70 % 


70% -85% 


99% 


Final elements 


50 % - 70 % 


70 % - 85 % 


99% 


NOTE 1 This table should be read in conjunction with table A.I of lEC 61508-2 which provides the failure modes to be 
, considered. 

NOTE 2 When a range is given for diagnostic coverage, the upper interval boundaries may be set only for narrowly 
tolerated monitoring means, or for test measures that stress the function to be tested in a highly dynamic manner. 

NOTE 3 For techniques where there is no high diagnostic coverage figure, at present no measures and techniques of 

high effectiveness are l<nown. 

NOTE 4 At present no measures and techniques of medium effectiveness are known for quarte clocks. 

NOTE 5 The minimum diagnostic coverage for a combination of temporal and logical program flow monitoring is medium. 



Useful references include those listed as [7]* to [9]. 



* Figu^Ts -in square brackets refer to the bibliography. 
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(informative) 



A meth©d©!©gy for qyaoitifying the effect ©f hardware-related 
eommon eayse failures m E/E/PE systems 

D.1 General 

This standard incorporates a number of measures which deal with systematic failures 
However, no matter how well these measures are applied, there is a residual probaoility of 
systematic failures occurring. Although this does not significantly affect the reliability 
calculations for single-channel systems, the potential for failures which may affect more than 
one channel in'a multi-channel system, i.e. common cause failures, results in substantial 
errors when reliability calculations are applied to multi-channel systems. 

This informative annex describes a methodology which allows common cause failures to be 
taken into account in the safety assessment- of multi-channel E/E/PE systems. Using the 
methodology gives a more accurate estimation of the integrity of such a system than ignoring 
the potential for common cause failures. 

The methodology is used to calculate a value for p, the ^-factor frequently used in the 
modelling of common cause failures. This can be used to estimate the rate of common cause 
failures applicable to two or more systems operating in parallel from the random hardware 
failure rate of one of those systems (see D.5). Alternative methodologies may be preferred in 
some cases, for example, where a more accurate ^-factor can be proven as a result of the 
availability of data on common cause failures. 

D-2 Brief overview 

The failures of a system are considered to arise from two causes: 

- random hardware failures; and 

- systematic failures. 

The former are assumed to occur randomly in time for any component and to result in a failure 
of a channel within a system of which the component forms part^ There is a finite probability 
that independent random hardware failures could occur in all channels of a multi-channel 
system so that all of the channels were simultaneously in a failed state. Because random 
hardware failures are assumed to occur randomly with time, the probability of such failures 
concurrently affecting parallel channels is low compared to the probability of a single channel 
failing. This probability can be calculated using well-established techniques. 

However, some failures, i.e. common cause failures .which result from a single cause, may 
affect more than one channel. These may result from a systematic fault (for example, a design 
or specification mistake) or an external stress leading to an early random hardware failure (for 
example, an excessive temperature resulting from the random hardware failure of a common 
cooling fan, which accelerates the life of the components or takes them outside their specified 
operating environment) or, possibly, a combination of both. Because common cause failures 
are likely to affect more than one channel in a multi-channel system, the probability of 
common cause failure is likely to be the dominant factor in determining the overall probability 
of failure of a multi-channel system and if this is not taken into account a realistic estimate of 
the safety integrity level of the combined system is unlikely to be obtained. 
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Although common cause failures result from a single cause, they do not all manifest 
themselves simultaneously in al! channels. For example, if a cooling fan fails; a!l of the 
channels of a multi-channel E/E/PE system could fail, leading to a common cause failure. 
However, all of the channels are unlikely to warm at the same rate or to have the same critical 
temperature. Therefore, failures occur at different times in the different channels. 

The architecture of programmable systems allows them to carry out internal diagnostic testing 
functions during their on-line operation. These can be employed in a number of ways, for 
example 

- a single channel PES can continuously be checking its internal operation together with the 
functionality of the input and output devices. If designed from the outset, a test coverage 
in the region of 99 % is achievable [10]. If 99 % of internal faults are revealed before they 
can result in a failure, the probability of single-channel faults which can ultimately 
contribute to common cause failures is significantly reduced. 

- in addition to internal testing, each channel in a PES can monitor the outputs of other 
channels in a multi-channel PES (or each PE device can monitor another PE device in a 
multi-PE system). Therefore, if a failure occurs in one channel, this can be detected and a 
safe shut-down initiated by the one or more remaining channels that have not failed and 
are executing the cross-monitoring test. (It should be noted that cross-monitoring is 
effective only when the state of the control system is continuously changing, for example 
the interlopk of a frequently used guard in a cyclic machine, or when brief changes can be 
introduced without affecting the controlled function.) This cross-monitoring can be carried 
out at a high rate, so that, just before a non-simultaneous common cause failure, a cross- 
monitoring test is likely to detect the failure of the first channel to fail and is able to put the 
system into a safe state before a second channel is affected. 

.In the case of the cooling fan example, the rate of temperature rise and the susceptibility of 
each channel are slightly different, resulting in the second channel failing possibly several 
tens of minutes after the first. This allows the diagnostic testing to initiate a safe shutdown 
before the second channel succumbs to the common cause fault. 

As a result of the above 

- PE-based systems have the potential to incorporate defences against common cause 
failures and, therefore, be less susceptible to them when compared to other technologies; 

- a different j3-factor may be applicable to PE-based systems when compared to other 
technologies. Therefore, j3-factor estimates based on historic data are likely to be invalid. 
(None of the existing investigated models used for estimating the probability of common 
cause failure allow for the effect of automatic cross-monitoring.) 

- because common cause failures that are distributed in time may be revealed by the 
diagnostic tests before they affect all channels, such failures may not be recognized or 
reported as being common cause failures. 

There are three avenues that can be taken to reduce the probability of potentially dangerous 
common cause failures. 
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.^ Reduce the number of random hardware and systematic failures overall, (This reduces the 
'^ areas o^^^^^^^ figure D.1 ieadingto a reduction in the area of overlap.) 

b) Maximize the independence of the channels. (This /educes the amount of overlap 
between the ellipses in figure D.1 whilst maintammg their area.) 

c) Reveal non-simultaneous common cause failures while only one, and before a second. 
channel has been affected, i.e. use diagnostic tests. 




Figure^ p.1 - Relationship of common cause failures to the failures of individual channels 



This standard IS based on these three avenues and requires a threefold approach. 

a) 'Apply the tect^niques specified in lEC 61508 to reduce the overall probability of systematic 

failure to a level commensurate with the probability of random hardware failure. 

b) Quantify those* factors that can be quantified, i.e. take into account the probability of 

random hardware failure, as specified in lEC 61508-2. 

c) Derive, by what is considered at the present time to be the best practicable means, a 
factor relating the prpbability of common cause failure of the hardware to the probability of 
random hardware failure. The methodology described in this annex relates to the 
derivation of this factor. 

Most methodologies for estimating the probability of common cause failures attempt to make 
their predictions from the probability of random hardware failure. Clearly, the justification for 
any direct relationship between these probabilities is tenuous, nevertheless, such a 
correlation has been found in practice-and probably results from second-order effects. For 
example, the higher the probability of random hardware failure of a system 

- the higher the amount of m^ntenance required by the system. The probability of a 
systematic fault being introducefl during maintenance depends on the number of times 
maintenance is carried out, and this also affects the rate of human errors leading to 
common cause failures. This leads to a relationship between the probability of random 
hardware failure and the probabiffty of common cause failure. For example 

44 



IS/JEC 61508«6:200Q 

o a repair, followed by testing and, possibly, recalibration is required each time a random 
hardware failure occurs; 

o for a given safety integrity level, a system with a higher probability of random hardware 
failure requires proof tests to be carried out more frequently and with , greater 
depth/complexity, leading to additional human interference. 

~ the more complex the system. The probability of random hardware failure depends on the 
number of components, and,, hence, the complexity of a system. A complex system is less 
easily understood, so is more prone to the introduction of systematic faults. In addition, 
the complexity makes it difficult to detect the faults, by either analysis or test, and can 
lead to parts of the logic of a system not being exercised except in infrequent 
circumstances. Again, this leads to a relationship between the probability of random 
hardware failure and the probability of common cause failure. 

Despite the limitations of the current models, it is believed that they represent the best way 
forward at the present time for providing an estimate of the probability of common cause 
failure of a multi-channel system. The methodology described in this annex uses an approach 
similar to the well-established ^-factor model as the third part of the threefold approach 
already described: 

The following two difficulties a-'e faced when using the ^-factor model on a E/E/PE system. 

- Vyhat value should be chosen for the j3-factor? Many sources (for example reference [10]) 
suggest ranges within which the value of the j3-factor is likely to occur but no actual value 
is given, leaving the user to make a subjective choice. To overcome this problem, the 
methodology in this annex is based on the system originally described in reference [11] 
and recently redefined in reference [12]. 

- The j3-factor model does not take- into account the sophisticated diagnostic testing 
capabilities of modern PESs, which can be used to detect a non-simultaneous common 
cause failure before it has had 'sufficient time to manifest itself fully. To overcome this 
deficiency, the approach described in references [11] and [12] has been modified to reflect 
the effect of diagnostic tests in the estim.ation of the likely value of j3. 

The diagnostic testing functions running within a PES are continuously comparing the 
operation of the PES with predefined states. These states. can be predefined in software or in 
hardware (for example, by a watchdog timer). Looked on in this way, the diagnostic testing 
functions may be thought of as an additional, and partially diverse, channel running in parallel 
with the PES. 

Cross-monitoring between channels also can be carried out. For many years, this technique 
has bee^used in dual-channel interlocking systems based solely on relays. However; with 
relay technology, it is usually possible to carry out the cross-checks only when the channels 
change state, making such tests inappropriate for revealing non-simultaneous com.mon cause 
failures where system,s remain in the same (for example, ON) state for long periods. With PES 
technology, cross-monitoring may be carried out with a high repetition frequency. 
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D.3 Scope of the methodology 

The scope of the methodology is limited -to common cause failures within hardware. The 
reasons for this include the following: 

- the j3-factor model relates the probability of common cause failure to the probability of 
random hardware failure. The probability of common cause failures which involve the 
system as a whole depends on the complexity of the system (possibly dominated by the 
user software) and not on the hardware alone. Clearly, any calculations based on the 
probability of random hardware failure cannot -take into account the complexity of the 
software; 

- reporting of common cause failures is generally limited to hardware failures, the area of 
most concern to the manufacturers of the^TilTdware; 

- it is not considered practicable to model systematic failures (for example software 
failures); 

- the measures specified in lEC 61508-3 are intended to reduce the probability of software- 
related common cause failure to an acceptable level for the target safety integrity level. 

Therefore, the estimate of the probability of common cause failure derived by this 
methodology relates to only those failures associated with the hardware. It should NOT be 
assumed that the methodology can be used to obtain an overall failure rate which takes the 
probability of software-related failure into account, 

D.4 Points taken mto account in the methodology 

Because sensors^ logic subsystem* and final elements are subject to, for example, different 
environmental conditions and diagnostic tests with varying levels of capability, the 
methodology should be applied to each of these subsystems separately. For example, the 
logic subsystem is more likely to be in a controlled environment, whereas the sensors may be 
mounted outside on pipework that is exposed to the elements. 

i 

\ 

Programmable electronic channels have the potential for carrying out sophisticated diagnostic 
testing functions. These can 

- have a high diagnostic coverage within the channels; 

- monitor additional redundancy channels; 

- have a high repetition rate; and 

- in an increasing number of cases, also monitor sensors and/or'final elements. 

A large fraction of common cause failures do not occur concurrently in all of the affected 
channels. Therefore, if the repetition frequency of the diagnostic tests is sufficiently high a 
large fraction of cgmmon cause failures can be revealed and, hence, avoided before thev 
affect all available channels, ^ 

Not all features of a multi-channel system, that have a bearing on its immunity to common 
cause failures, can be evaluated by diagnostic tests. However, those features relating to 
timfS °' '"d®P^"dence are made more effective. Any feature which is likely to increase the' 

ime between channel failures in a non-simultaneous common cause-failure (or reduce the 
Sfn Jlf'"" J,f"?f com.rnon cause failures) increases the probability of the diagnostic 

.Sfinn t ^ ^^ ?'^"'^ ^""^ P""'"9 the plant into a safe state. Therefore, the features 
relating to immunity to common cause failures are divided into those whose effect is thouaht 

o be increased by the use of diagnostic tests and those whose effect is not Th rieads to the 
two columns. X and Y respectively, in table D.I. 
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Although, for a three-channel system, the probability of common cause failures which affect 
all three channels is likely to be slightly lower than the probability of failures which affect two 
channels, it is assumed, in order to simplify the methodology, that the probability is 
independent of the number of affected channels, i.e. it is assumed that if a common cause 
failure occurs it affects all channels. 

There is no known data on hardware-related common cause failures available for the 
calibration of the methodology. Therefore, the tables in this annex are based'on engineering 
judgement. 

Diagnostic test routines are sometimes not regarded as having a direct safety role so may not 
receive the same level of quality assurance as the routines providing the main control 
functions. The methodology was developed on the presumption that the diagnostic tests have 
an integrity commensurate with the target safety integrity level. Therefore, any software- 
based diagnostic test routines should be developed using techniques appropriate to the target 
safety integrity level. 

D.5 Using the fi-iaotor to calculate the probability of failure in an E/E/PE safety- 
related system due to common cause failures 

Consider the effect of common cause failures on a multi-channel system with diagnostic tests 
running within each of its channels. 

Using the j3-factor model, the probability of dangerous common cause failures is 

where Ao is the probability of dangerous random hardware failures for each individual channel 
and j8 is the j8-factor in the absence of diagnostic tests, i.e. the fraction of single-channel 
failures that affect all channels. 

We now assume that common cause failures affect all channels, and that the span of time 
between the first channel and all channels being affected is small compared to the time 
interval between successive common cause failures. 

Suppose that there are diagnostic tests running in each channel which detect and reveal a 
fraction of the failures. We can divide all failures into two categories; those that lie outside the 
coverage of the diagnostic tests (and so can never be detected) and those that lie within the 
coverage (so would eventually be detected by the diagnostic tests). 

The overall probability of failure due to dangerous common cause failures is then given by 

^DuP'^ ^ddPd 
where 

Xdu is the probability of an undetected failure of a single channel, i.e. the probability of 
failures which lie outside the coverage of the diagnostic tests; clearly, any reduction in the 
j8-factor resulting from the repetition rate of the diagnostic tests cannot affect this fraction 
of the failures; 
- j3 is the common cause failure factor for undetectable dangerous faults, which is equal to 
the overall j3-factor that would be applicable in the absence of diagnostic testing. 
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Ann is the probability of a detected failure of a single channel, i.e the probability of 
' f aifu es o? a Se channel that lie within the coverage of the diagnostic tests; here, if the 
repSn rate of the diagnostic tests is high, a fraction of the failures are revealed leading 
to a reduction in the value of j3. i.e. Pd\ 

- Bn is the common cause failure factor for detectable dangerous faults. As the repetition 
rate of the diagnostic testing is increased, the value of po falls increasingly below /J. 

- ^ is obtained from table D.4. using a score, S= X+ V (see D.6); 

- Pd is'obtained from table D.4, using a score, S^ = X(Z + 1) + Y . 

D.6 Using the tables to estimate p 

The /3-factor should be calculated for the sensors, the logic subsystem and the final elements 
separately. 

In order to minimize the probability of occurrence of common cause failures, one should first 
establish which measures lead to an efficient defence against their occurrence. The 
implementation of the appropriate measures in the system lead to a reduction in the value of 
the j3-factor used in estimating the probability of failure due to common cause failures. 

Table D.1 lists the measures and contains associated values, based on engineering 
judgement, which represent the contribution each measure makes in the reduction of common 
cause failures. Because sensors and final elements are treated differently to the 
programmable electronics, separate columns are used in the table for scoring the 
programmable electronics and the sensors or final elements. 

Extensive diagnostic tests may be incorporated into programmable electronic systems which 
allow the detection of non-simultaneous common cause failures. To allow diagnostic tests to 
be taken into account in the estimation of the ^-factor, the overall contribution of each 
measure in table, D.1 is divided, using engineering judgement, into two sets of values, X 
and Y, For each measure, the X:Y ratio represents the extent to which the measure's 
contribution against common clause failures can be improved by diagnostic testing. 

The user of table D.1 should ascertain which measures apply to the system in question, and 
sum the corresponding values shown in each of columns Xts and Yis for the logic subsystem, 
or XsF and Ysf for the sensors or final elements, the sums being referred to as X and /, 
respectively. 

Tables D.2 and D.3 may be used to determine a factor Zfrom the frequency and coverage of 
the diagnostic tests, taking into account the important note 4 which limits when a non-zero 
value of Z should fae used. The score S is then calculated using the following equations, as 
appropriate (see previous clause):* 

- S= X+ / to obtain the value of j3 (the jS-factorfor undetected failures); and 

- So = X{Z+i} + Y to obtain the value of Jio (the ^-factor for detected failures). 

Here S or So is a score which is used in table D.4 to determine the appropriate ^-factor. 
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Table D.1 - Scoring programmable electronics or sensors/final elements 



Item 


Logic 
subsystem 


Sensors and 
final elements 


Xls 


Vts 


XsF 


YSF 


Separation/segregation 1 


Are all signal cables for the channels routed separately at al! positions? 


1.5 


1.5 


1,0 


2.0 


Are the logic subsystem channels on separate printed-circuit boards? 


3.0 


1,0 






Are the logic subsystem channels in separate cabinets? 


2.5 


•0.5 






If the sensors/final elements have dedicated control electronics, is the electronics for each 

channel on separate printed-circLiit boards? 






2,5 


1.5 


if the sensors/final elements have dedicated control electronics, is the electronics for each 
channel indoors and in separate cabinets? 






2,5 


0.5 


Diversity/redundancy 1 


Do the channels employ different electrical technologies 

for example, one electronic or programmable electronic and the other relay? 


7.0 








Do the channels employ different electronic technologies 

for example, one electronic, the other programmable electronic? 


5.0 








Do the devices employ different physical principles for the sensing elements 

for example, pressure and temperature, vane anemometer and Dopp[er transducer, etc? 






7,5 




Do the devices employ different electrical principles/designs 

for example, digital and analogue, different manufacturer (not re-badged) or different 

technology? 


2.0 




5,5 




Do the channels employ enhanced redundancy with MooN architecture, where A/> M+ 2 ? 


0,5 


2.0 


0,5 


Do the channels employ enhanced redundancy with MooN architecture, where 'N= M+2? 


1,0 


0.5 


1.0 


0,5 


Is low diversity used, for example hardware diagnostic tests using the same technology? 


2.0 


1.0 






js medium diversity used, for example hardware diagnostic tests using different technology? 3,0 


1.5 






Were the channels designed by different designers with no communication between them 
during the design activities? 


1rO 


1.0 






Are separate test methods and people used for each channel during commissioning? 


1.0 


0.5 


1,0 


1,0 


Is maintenance on each channel carried out by different people at different times? 


2.5 J 


2.5 




Complexlty/design/apptication/maturity/experience 




1 


Does cross-connection between channels preclude the exchange of any information other 
than that used for diagnostic testing or voting purposes? 


0.5 


0.5 


0,5- 


0.5 


Is the design based on techniques used in equipment that has been used successfully in 
the field for > 5 years? 


0.5 


1.0 


\0 


1.0 


Is there more than 5 years experience with the same hardware used in sirfii'ar 
environments? 


1.0 


1.5 


1.5 


1,5 


Is the system simple, for exaniple no more than 10 inputs or outputs per channel? 




1.0 






Are inputs and outputs protected from potential levels of over- voltage and over-current? 


1,5 


0.5 


1,5 


0,5 


Are all devices/components conservatively rated (for example, by a factor of 2 or more)? 


2.0 




2,0 




Assessment/analysis and feedback of data 1 


Have jhe results of the failure modes and effects analysis or fault-tree analysis been 
examined to establish sources of common cause failure and have predetermined sources of 
common cause failure been eliminated by design? 




3.0 




3.0 


Were common cause failures considered in design reviews with the results fed back into the 
design? (Documentary evidence of the design review activity is required.) 




3.0 




3,0 


Are all field failures fully analyzed with feedback into the design? (Documentary evidence of 
the procedure is required.) 


0,5 


3,5 


0,5 


3.5 
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Table D.1 (continued) 



Item 



Logic 
subsystem 



Xls Yls 



Sensors and 
final elements 



XsF 



Proc edur^s/iiuman interface — _ — : 

Is there a written system of work to ensure that all component failures (or degradations) are 
detected, the root causes established and other similar items inspected for similar potential 
causes of failure? 



Are procedures in place to ensure thai: maintenance (including adjustment or calibration) of 
any paVt of the independent channels is staggered, and, in addition to the manual checks 
carried out following maintenance, the diagnostic tests are allowed to run satisfactorily 
between the completion of maintenance on one channel and the start of maintenance on 
another? 



Do the documented maintenance procedures specify that all parts of redundant systems 
(for example, cables, etc) intended to be Independent of each, other, are not to be 
relocated? " i_ 



Is a)! maintenance of printed-circuit boards, etc. carried out off-site at a qualified repair 
centre and have all the repaired items gone through a full pre-instailation testing? 



Does the system have tow diagnostic coverage (60 % to-90 %) and report failures to the 
level of a field- replaceable module? 



1.5 



0.5 



0.5 



1.5 



0,5 



0.5 



1,0 



0.5 



2,0 



0,5 



0.5 



YsF 



1.5 



1.0 



0.5 



1,5 



0.5 



Does the system have medium diagnostics coverage (90 % to 99 %) and report failures to 
the level of a fieid-reptaceabte modul e? 



1.5 



1.0 



Does the system have high diagnostics coverage (>99 %) and report failures to the level of 
a fieid-replaceab^ e module? 



2.5 



1,5 



Does the sys tem dia gnostic tests report faiJures to th e ie vei of a field-replacea ble modu le? 
Compgtence/training /sa fety culture 



1.0 



Have designers been trained (with training documentation) to understand the causes and 
consequences of common cause-failures? 



Have maintainers been trained (with training documentation) to understand the causes and" 

consequences of commo n cause fail ures? ' 

Environmen tal control 



2,0 



3,0 



2.0 



1.0 



3,0 



0.5 



4.5 



0.5 



Is personnel access iimite d (for example locked cab in ets, inaccessible positio n)? 



Is the system likely to operate always within the range of temperature, humidity, corrosion, 
dust, vibration, etc., over which it has been tested, without the use of external environmental 
control? 



Are all signal and power c ables separate a t alt positions? 
Environmental testing 



0.5 



3.0 



2.0 



2,5 



1.0 



1,0 



0.5 



3,0 



2.0 



Has the system been tested for immunity to all relevant environmental influences (for 
example EMC, temperature, vibration, shock, humidity) to an appropriate level as specified 
in recognized standards?^ 



10.0 



10.0 



10.0 



4.5 



2,5 



1.0 



1.0 



10,0 



NOTE 1 A number of the items relate to the operation of the system, which may be difficult to predict at design time In 
these cases, the designers should make reasonable assumptions and subsequently ensure that the eventual user of the 
system is made aware of, for example, the procedures to be put in place in on^er to achieve the designed level of safetv 
integnty. This could be by including the necessary information in the accompanying documentation. 

l^tlo HI \^^^')'^^'^J^•! ^^"^ ^columns are based on engineering judgement and take into account the indirect as weil 
as the direct effects of the items in column 1 . For example, the use of field-replaceable modules leads to 



'fAiii 
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Tabfe D.2 - Value of Z: programmable electronics 



Diagnostic 
coverage 


Diaqnostia test interval 


Less than 1 min 


Between 1 min and 5 min 


Greater than 5 min 


>: 99 % 


2.0 


1.0 





> 90 % 


1.5 


0.5 





^ > 60 % 


1.0 









Table D.3 - Value of Z: sensors or final elements 



Diagnostic 
coverage 


Diagnostic test interval | 


Less than 2 h 


Between 2 h and 
two days 


Between 2 days 
and one weelt 


Greater than one 
week 


>99% 


2.0 


1,5 


1.0 





>90% 


1.5 


1.0 


0.5 





^60% 


1.0 


0.5 





. 



NOTE 1 The methodology is most effective if account is taken uniformly across the list of the categories in 
table D.I., Therefore, it is strongly recommended that the total score in the X and Y columns for each category 
should be'not less than the total score in the Xand /columns divided by 20. For example, if the total score (X + Y) 
is 80, none of the categories (for example^ procedures/human interface) should have a total score (X + V) of less 
than four. 

NOTE 2 When using table 0.1, take account of the scores for all items that apply. The scoring has been designed 
to allow for items which are not mutually exclusive. For example, a system with logic subsystem channels in 
separate racks is entitled to both the score for "Are the logic subsystem channels in separate cabinets?- and that 
for "Are the logic subsystem channels on separate printed-circuit boards?" 

NOTE 3 If sensors or final elements are PE-based, they should be treated as part of the logic subsystem if they 
are enclosed within the same building (or vehicle) as the device that constitutes the major part of the logic 
subsystem, and as sensors or final elements if they are not so enclosed. 

NOTE 4 For a non-zero value of Z to be used, it should be ensured that the equipment under control is put into a 
safe state before a non-simultaneous commcOn cause failure can affect all the channels. The time taken to assure 
this safe state should be less than the claimed diagnostic test interval. A non-zero value for Z can be used only if 

- the system initiates an automatic shut-down on detection of a fault; or 

- a safe shut-down is not initiated after a first fault ^), but the diagnostic tests 

o determine the locality of the fault and are capable of localizing the fault, and 

o continue to be capable of placing the EUC in a safe state after the detection of any subsequent faults; or 

- a formal system of work is in place to ensure that the cause of any revealed fault Is fu!ly investigated within the 
claimed diagnostic test interval and 

o if the fault has the potential for leading to a common cause failure, the plant is immediately shut-down, or 



the faulty channel is repaired within the claimed diagnostic test interval. 



Mnrc ^ In thP nrocGss Industries it is unlikely to be feasible to shut down the EUC when a fault is detected 

value of Z may be used. 

is the total coverage provided by all of the modules. 



1) 



Th'e'oVera'^^n Of the system on the f -ification of a fault ^hould be ta.en into acoount.^For --g- a.^simpje 

2003 system should be shut dowri (or ^^P^^'^^^^f^.^^l Sa second channel could result in the two failed 
identification of a single failure. If \h:s is not done a «a,lu ^ o, a sec° ^^ reconfigures itself to loo2 

channels outvoting the remammg (good) ^''.l""^!.^,^^^^^^^ on the occurrence of a second failure, has 

rrn^crredToSS' T^^^t Sn'S'L^ d channel and so a non-.ero value for Z may be 
claimed, c-i 
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Table D.4 - Calculation of ^ or Po 



Score (S or So) 


Corresponding value of fi or Po for the: 


Logic subsystem 


Sensors or final 
elements 


120 or above 


0.5 % 


1 % 


70 to 120 


1 % 


2% 


45 to 70 


2% 


5% 


Less than 45 


5% 


10% 


NOTE 1 The maximum levels of Po shown in this table are lower than 
would normally be used, reflecting the use of the techniques > specified 
elsewhere in this standard for the reduction in the probability of systematic 
failures as a whole, and of common cause failures as a result of this. 

NOTE 2 Values of Po lower than 0.5 % for the logic subsystem and 1 % 
for the sensors would be difficult to justify. 



0.7 Examples of the use of the methodoSogy 

In order to demonstrate the effect of using the methodology, sorne simple examples have 
been worked through in table'D.5 for the programmable electronics. 

For categories not relating to diversity nor redundancy, typical values for X and Y were used. 
These were obtained ^y halving the maximum score for the category. 

In the diverse system examples, the values for the diversity/redundancy category are derived 
. from the following properties considered in table D.I: 

- one system is electronic, the other uses relay technology; 

- the hardware diagnostic tests use different technologies; 

- the different designers did not communicate during the design process; 

- different test methods and test personnel were used to commission the systems; and' 

- maintenance is carried out by different people at different times. 

In the redundancy system examples, the values for the diversity/redundancv cateaorv arp 
derived from the property that the hardware diagnostics are carrLd out by a^riSpenden" 
system, which uses the same technology as the redundancy systems. maependent 

?LrnJ^to%l7?x^a^;t:Jsrm\"?n\S"^^' ^"^^'''"^""^ ^"^ "^'■"'■"^- -'- ^^ ^^^ ^- 
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Table D.5 - Example values for programmable electronics 



Category 


Diverse system 

with good 

diagnostic testing 


Diverse system 

with poor 

diagnostic testing 


Redundancy 
system with good 
diagnostic testing 


Redundancy 
system with poor 
diagnostic testing 


Separation/segregation 


X 


3,50 


3.50 


3.50 


3.50 


y 


1.50 


1.50 


1,50 . 


1,50 


DiversJty/redunaancy ' 


X 


14.50 


14.50 


2,00 


2,00 


y 


3,00 


3,00 


1.00 


1.00 


Complexity/design/ 


X 


2J5 


2,75 


2.75 


2.75 


y 


2,25 


2.25 


2,25 - 


2.25 


Assessment/analysis/. . . . 


X 


0,25 


0.25 


0.25 


0.25 


y 


4,75 


4.75 


4,75 . 


4.75 


Procedures/human interface 


X 


3.50 


3.50 


3,50 


3.50 


y 


3.00 . 


3,00 


3.00 


3.00 


Competence/training/... 


X 


1,25 


1.25 


1.25 


1.25 


Y 


3.75 • 


3,75 


3,75 


3.75 


Environmenla! control 


X 


2.75 


2.75 


2,75 


2,75 


y 


2,25 


2.25 


2.25 


2,25 


Environmental test 


X 


5.00 


5.00 


5.00 


5.00 


y 


5.00 


5,00 


5.00 


5.00 


Diagnostic coverage 


z 


2.00 


0.00 


2,00 


0.00 


Total X 


33.5 


33,5 


21 


21 


Total V 


25,5 


25,5 


23,5 


23.5 


Score S 


59 


59 


44.5 


•44,5 


p 


2% 


2% 


5% 


5% 


Score Sd 


126 


59 


86.5 


44,5 


Po 


0,5 % 


2% 


1 % 


5% 



D.8 References 

References [10] to [12] provide useful information relating to common cause failures. 
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(informative) 



Example appiicatJons of software safety integrity tabres of lEC S1 508-3 



E.1 General 

This annex gives two worked examples in the application of the software safety integrity 
tables specified in annex A of lEC 61508-3. 

The first example is a safety integrity level 2 programmable electronic safety-related system 
required for a process within a chemical plant. The programmable electronic safety-related 
system utilizes ladder logic for the application program, and is an illustration of limited 
variability language application programming. 

The second example is a shut-down application based on a high-level language, of safety 
integrity level 3. 

Both worked examples provide guidance on how the software safety integrity tables might be 
applied in different circumstances. For a real system all the entries in the tables should be 
supported by documented justification that the comments made are correct and that they 
represent an appropriate response for the particular system and application. 

E.2 Example for safety integrity level 2 

The application consists of several reactor vessels linked by intermediate storage vessels 
which are filled with inert gas at certain points in the reaction cycle to suppress ignition and 
explosions. The programmable electronic safety-related system functions. include; receiving 
inputs from the sensors; energizing and interlocking the valves, pumps and actuators; 
detecting dangerous situations and, activating the alarm; interfacing to a distributed control 
system, as required by the safety requirements specification. 

Assumptions: 

- the programmable electronic safety-related system controller is a PLC; 

- the hazard and risk analysis has established that a programmable electronic safety- 
related system is required, and that safety integrity level 2 is required in this application 
(by the application of lEC 61508-1 and lEC 61508-2); 

- although the controller operates in real time, only a relatively slow response is needed; 

- there are interfaces to a human operator and to a distributed control system; 

- the source code of the system software and the design of the programmable electronics of 
the PLC is not available for examination, but has been qualified against !EC 61508 to 
safety integrity level 2; - 

- the language used for application programming is ladder logic, produced using the PLC 
suppliers development system; 



- the applicafioPT'code is required to run on only a single type, of PLC; 

- the whole of the software development was reviewed by a person independent of the 

software team; 

- a person independent of the software team witnessed and approved the validation testing; 
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- modifications (if needed) require authorization by a person independent of the software 
team. 

NOTE 1 For the definition of an independenrperson, see 3.8.10 of »EC 61508-4. 

The following tables show how annex A of lEC 61508-3 may be interpreted for this 
application. « 

NOTE 2 In the reference columns (entitled Ref) of the following tables, the technique/measure subclauses 
(e.g. B.2.4, C.3.1) refer to lEC 61508-7 and the tables (e.g, table B.7) refer to lEC 61508-3. 

NOTE 3 See the notes to 7.4.3, 7.4.4 and 7.4.5 of iEC 61508-3 for information on the division of responsibility 
.between supplier and user when limited variability programming is used. 



Table E.1 - Software safety requirements specification (see 7.2 of IEC 61508-3) 



/ Technique/measure 


Hef 


SIL2 


Interpretation in this application 


1 Computer-aided specification tools 


B.2.4 


R 


Development tools supplied by the PLC 
manufacturer 


2a Semi-formal methods 


Table 
B.7 


R 


Cause-effect diagrams, sequence diagrams, 
function blocks. Typically used for PLC application 
software requirements specification 


2b Formal methods including for example, 
CCS, CSP, HOL. LOTOS, OBJ. temporal 
logic, VDM and Z 


C.2.4 


R 


Not used for limited variability programming 


NOTE The software safety requirements were specified in natural language. | 
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Table E.2 - Software design and development: 
software architecture design (see 7.4.3 of lEC 81508-3) 



Technique/measure 


Ret 


SIL2 


Interpretation in this application 


1 Fault detection and diagnosis 


C.3.1 


R 


Checking of data range, watch-dog timer, I/O, 
communication. Raise an alarm if errors (see 3a) 


2 Error detecting and correcting codes 


C.3.2 


R 


Embedded with user options - careful selection 
required 


3a Failure assertion programming 


C.3.3 


R 


Dedicate some PLC program ladder logic to test 
certain essential safety conditions (see 1) 


3b Safety bag techniques 


C.3.4 


R 


Check legal I/O combinations in an independent 
hardware safety monitor 


3c Diverse programming 


C.3.5 


R 


Required by the application (see 3b) 


3d Recovery block 


0.3.6 


R 


Embedded with user options - careful selection 
required 


3e Backward recovery 


C.3.7 


R 


Embedded with user options - careful selection 
required 


3f Fonward recovery 


C.3.8 


R 


Embedded with user options -careful selection 

required 


3g Re-try fault recovery mechanisms 


C,3.9 


R 


Used as required by the application (see 2 and 
3b) 


3h Memorizing executed cases 


C.3.10 


R 


Not used for limited variability programming 


4 Graceful degradation 


C.3.1 1 


R 


Not used for limited variability programming 


5 Artificial intelligence fault correction 


C.3.1 2 


NR 


Not used for limited variability programming 


6 Dynamic reconfiguration 


C.3-13 


NR 


Not used for limited variability programming 


7a Structured methods including for. 
' example. JSD. MASCOT, SADT and 
Yourdon. 


C.2.1 


HR 


Data flow methods and data logic tables may be 
used for representing at least the design 
architecture 


7b Semi-formal methods 


Table 
B.7 


R 


May be used for DCS interface 


7c Formal methods including for example, 
CCS. CSP. HOL, LOTOS. OBJ. temporal 
logic, VDM and 2 


C.2,4 




Rarely used for limited variability programming 


8 Computer-aided specification tools 


B.2.4 


R t 

) 
t 


Development tools supplied by the PLC 
manufacturer 


NOTE It is impractical, to implement some of the above techniques in limited variability programming. 



Table E.3 - Software design, and development: 
support tools and programming language (see 7.4.4 of lEC 61508-3) 



Technique/measure 


Ref 


SIL2 


Interpretation in this application 


1 Suitable programming language 


a4.6 . 


HH 


Usually ladder, and often the proprietary variety of 

the PLC supplier 


2 strongly typed programming language 


C.4.1 


HR 


lEC 61 131-3 structured text 


3 Language subset 


C.4.2 


— 


Beware of complex "macro" instructions, interrupts 
which alter PLC scan cycle, etc. 


4a Certified tools 


C.4,3 


HR 


Available from some PLC manufacturers 


4b Tools: increased confidence from use 


C.4.4 


HR 


PLC supplier's development kit; in-house toois 
developed over several projects 


5a Certified translator 


C.4.3 


HR 


Available from some PLC manufacturers 


5b Translator: increasedconfidence from 
use 


C.4.4 


HR 


Not used for limited variability. programming 


6 Library of trusted/verified software 
modules and components 


C.4.5 


HR 


Function blocks, part programs 
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Table E-4 - Software design and development: 

detailed design {see 7.4.5 and 7.^.6 of lEC 81508-3) 

(this includes software system design, software module design and coding) 



Technique/measure 


Ref 


S1L2 


Interpretation in this application 


la Structured methods including for 
example, JSD, MASCOT, SADT and 
Yourdon 


C.2.1 


HR 


Not used for limited variability programming 


lb Semi-fomial methods 


Table B.7 


HR 


Cause-effect diagrams, sequence diagrams, . 
function blocks. Typical for limited variability 
programming 


1c Formal methods including for example, 
CCS, CSP, HOL, LOTOS, OBJ, 
temporal logic, VDM and Z 


C.2.4 


R 


Not used for limited variability programming 


2 Computer-aided design tools 


B.3.5 


R 


Development tools supplied by the PLC 
manufacturer 


3 Defensive programming 


C.2.5 


R 


Included in the system software 


4 Modular approach 


Table B.9 


HR 


Order and group the PLC program ladder logic .to 
maximize its modularity with respect to the 
functions required - 


5 Design and coding standards 


Table B.I 


HR 


In-house conventions for documentation and 
maintainability 


6 structured programming 


C.2.7 


HR 


Similar to modularity in this context 


7 Use of trusted/verified software modules 
and components (if available) 


C.4.5 


HR 


Used 



Table E.5 - Software design and development: 
software module testing and integration (see 7,4:7 and 7.4.8 of lEC 61508-3) 



Technique/measure 


Ref 


SIL2 


Interpretation in this application 


1 Probabilistic testing 


C.5.1 


R 


Not used for'limited variability programming 


2 Dynamic analysis and testing 


B.6.5 
Table B.2 


HH 


Used 


3 Data recording and analysis 


. C.5.2 


HR 


Records of test cases and results 


4 Functional and black box testing 


B.5.1 
B.5.2 

Table B.3 


HR 


Input data is selected to exercise alt specified 
functional cases, including error handling. Test 
cases from cause consequence diagrams, 
boundary value analysis, and input partitioning 


5 Performance modelling 


C.5.20 
Table B.6 


R 


Not used for liniited variability programming 


6 Interface testing 


' C.5.3 


R 


Included in functional and black-box testing 



Table E.S - Programmable electronics integration (hardware and software) 

(see 7.5 of lEC 61508-3) 



Technique/measure 


Ref 


SIL2 


Interpretation in this.application 


1 Functional and black-box testing 


* B.5.1 
' B.5.2 
Table B.3 


. HR 


input data is selected to exercise all specified 
functional cases, including error handling. Test 
cases from cause consequence diagrams, 
boundary value analysis, and input partitioning 


2 Performance testing 


C.5.20 
' Table B,6 " 


R 


When the PLC system is assembled for factory 
acceptance test 
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Table E.7 - Software safety validation (see 7.7 of lEC 61508-3) 



Technique/measure 



Probabilistic testing 



Simulation/modeiling 



3 Functional and black-box testing 



Ref 



C.5.1 



Tab!e B,5 



B.5.1 

B.5.2 

Table B.3 



SIL2 



R 



HR 



interpretation in this application 



Not used tor limited variability propramming 



Not used for limited variability programming, but 
becoming more commonly used in PLC systems 

development 



Input data is selected to exercise all specified 
functional cases, including error handling. Test 
cases from cause consequence diagrams, 
boundary value analysis, and input partitioning 



Table E.8 - Software modification (see 7.8 of lEC 61508-3) 



Technique/measure 


Ref 


SIL2 


Interpretation in this application 


1 Impact analysis 


C.5.23 


HR 


An impact analysis is carried out to consider 
how the effect of the proposed changes is 
limited by the modularity of the overall system 


2 Reverify changed software module 


C.5.23 


HR 


Repeat earlier tests 


3 Reverify affected software modules 


C.5,23 


HR 


Repeat earlier tests 


4 Revalidate complete system 


C.5.23 


R 


Impact analysis showed that the modification is 
necessary, so revalidation is done as required 


5 .Software configuration management 


C.5.24 


HR 


Baselines, records of changes, impact on other 
system requirements 


6 Data recording and analysis 


C.5.2 


HR- 


Records of test cases and results 



Table E.9 - Software verification (see 7.9 of part 3) 



Technique/measure 



Ref 



SIL2 



interpretation in this application 



Formal proof 



C.5.13 



Not used for limited variability programming 



2 Probabilistic testing ' 



C.5.1 



Replaced by operating experience of existing 
parts 



3 Static analysis 



B.6.4 
Table B.8 



HR 



Clerical cross-referencing of usage of variables, 
conditions, etc. 



4 Dynamic analysis and testing 



B.6.5 
Table B.2 



HR 



Automatic test harness to facilitate regression 
testing 



5 Software complexity metrics 



C.5.14 



R I Not used for limited variability programming 



Software module testing and integration 



See table E.5 



Programmable electronics integration testing 



See table E6 



Software system testing (validation) 



See table E.7 
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Table E.10 - Functional safety assessment (see clause 8 of lEC 61508-3) 



Technique/measure 


Ref 


SiL2 


Interpretation in this application 


1 Checklists 


B.2.5 


R 


Used 


2 Decision/truth tables 


c.ai 


R 


Used to a limited degree 


3 Software complexity metrics 


C.5.14 


R 


Not used for limited variability programming 


4 Failure analysis 


Table B.4 


R 


Cause-consequence diagrams at system level, 
but othenA/ise. failure analysis is not used for 
limited variability programming 


5 Common cause failure analysis of 
diverse software (if diverse software is 
actually used) 


C.6.3 


R 


Not used for limited variability programming 


6 Reliability block diagram 


C.6.5 


R 


Not used for limited variability programming 



E.3 Example for safety integrity level 3 

The software system is relatively large in terms of safety systems; more than 30 000 lines of 
source code are developed specifically for the system. Also the usual intrinsic functions are 
used - at least two diverse operating systems and pre-existing code from earlier projects 
(proven in use). In total, the system constitutes more than 100 000 lines of source code, if it 
were available as such. 

The whole hardware (including sensors and actuators) is a dual-channel system with its 
outputs to the final elements connected as a logical AND. 

Assumptions: 

>r- although fast response is not required a maximum response time is guaranteed; 

- there are interfaces to sensors, actuators and annunciators to human operators; 

- the source code of the operating systems, graphic routines and commercial mathematical 
routines is not available; 

- the system is very likely to be subject to later changes; 

- the specifically developed software uses one of the common procedural languages; 

- it is partially object oriented; 

- all parts for which source code is not available are implemented diversely, with the 
software components being taken from different suppliers and their object code generated 
by diverse translators; 

^ the software runs on several commercially available processors that fulfil the requirements 
of lEC 61508-2; 

- all requirements of lEC 61508-2 for control and avoidance of hardware faults are fulfilled 
by the embedded system; and 

- the software development was assessed by an independent organization. 

NOTE 1 For the definition of an independent organization, see 3.8.12 of lEC 61508-4. 

The following tables show how the annex tables of lEC 61508-3 may be interpreted for this 
application. 

NOTE 2 In the reference columns (entitled Ref) of the following tables, the technique/measure subclauses (e.g. 
B.2.4. C.3.1) refer to lEC 61508-7 and the tables (e.g. table B.7) refer to lEC 61508-3. 
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Table E.11 - Software safety requirements specification (see 7.2 of iEC 61508-3) 



Technique/measure 


•Ref 


SIL3 


Interpretation in this application 


1 - Computer-aided specification tools 


B.2.4 


HR 


Tools supporting the chosen methods 


2a Semi-formal methods 


Table 
B.7 


HR 


Block diagrams, sequence diagrams, state 
transition diagrams 


2b Formal methods including for example, 
CCS.CSP, HOL. LOTOS, OBJ, temporal 
logic, VDM and 2 


C.2.4 


^ R 


Only exceptionally 



7a 



Table E.12 - Software design and development: 
software architecture design (see 7.4.3 of SEC 61508-3) 



Technique/measure 



Fault detection and diagnosis 



2 Error detecting and correcting codes 



3a Failure assertion programming 



3b Safety-bag techniques 



3c Diverse programming 



3d Recovery block 



3e Backward recovery 



3f Forward recovery 



3g Re-try fault recovery mechanisms 



3h Memorizing executed cases 



4 "Graceful degradation 



5 Artificial intelligence - fault correction 



6 Dynamic reconfiguration 



Structured methods including for 
example, JSD, MASCOT, SADTand 
Yourdon, 



7b Semi-formal methods 



7c 



Formal methods including for example 
CCS. CSP. HOL, LOTOS. OBJ. temporal 
logic. VDM and Z 



Ref 



C.3.1 



C.3.2 



C.3.3 



C.3.4 



C.3.5 



a3.6 



C.3.7 



C.3.8 



C,3.9 



C.3.10 



C.3.1 1 



C.3.12 



C.3.1 3 



C.2.1 



8 Computer-aided specification tools 



C.2.4 



SIL3 



HR 



interpretation in this application 



-5- 

R 



Used as far as dealing with sensor, actuator and 
data transmission failures and which are not 
covered by the measures within the embedded 
system according to the requirements 
of IEC 61508-2 



Only for external data transmissions 



Results of the application functions are checked 
for validity 



Used for some safety related functions where 3a 
and 3c are not used 



Used for some functions where source code is not 
available 



Not used 



Not used 



B.2.4 



R 



HR 



NR 
NR 



HR 



Not used 
Not used 



Not used (measures 3a, 3b and 3c are sufficient) 



Yes. because of the nature of the technical 
process 



Not used 



Not used 



HR 



HR 



Needed because of the size of the system 



Block diagrams, sequence diagrams, state 

transition^diagrams 

Not used 



Tools^supporting the chosen method 
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Table E.13 - Software design and development: 
support tools and programming language (see 7.4.4 of !£C €1508-3) 



Technique/measure 


Ref 


SIL3 


Interpretation in this appJication 


1 Suitable programming language 


C.4.6 


HR 


Full variability high-leve! language selected 


2 Strongly typed programming language 


0.4.1 


HR 


Used 


3 Language subset 


C.4.2 


HR 


Defined subset for the selected language 


4a Certified tools 


C.4.3 


HR 


Not available 


4b Tools: increased confidence from use 


C.4.4 


HR 


Available, and used 


5a Certified translator 


C.4.3 


HR 


Not available 


5b Transiatgr: Increased confidence from 
use 


C.4.4 


HR 


Avaifabie, and used 


6 Library cjff trusted/verified software 
module^ and components 


C.4.5 


HR 


Available, and used 



Table E,14 - Software design and development: 
detailed design (see 7.4.5 and 7.4.6 of fEC 61508-3) 

(this includes software systenn design, software module design and coding) 



Technique/measure 


Ref 


S1L3 


interpretation in this application 


la Structured methods including for 

example, JSD, MASCOT, SADT and 
Yourdon 


C.2.1 


HR 


Widely used. In particular, SADT and JSD 


1 b Semi-formal methods 


Table B.7 


HR 


Finite state machines/state transition diagrams, 
block diagrams, sequence diagrams 


1 c Formal methods including for example, 
CCS, CSP. HOL, LOTOS, OBJ, 
.temporal logic, VDM and Z 


C.2.4 


R 


Only exceptionally, for some very basic components 
only 


2 Computer-aided design tools 


B.3.5 


HR 


Used for the selected methods 


3 Defensive programming 


C.2.5 


HR 


All measures except those which are automatically 
inserted by the compiler are explicitly used in 
application software where they are effective 


4 iVtodular approach 


Table B.9 


HR 


Software module size limit, information 
hiding/encapsulation, one entry/one exit point In 
subroutines and functions, fully defined interface, ... 


5 Design and coding standards 


Table 8,1 


HR 


Use of coding standard, no dynamic objects, no 
dynamic variables, limited use of interrupts, limited ' 
use of pointers, limited use of recursion, no 
unconditional jumps, ... 


6 Structured programming 


C.2,7 


HR 


Used 


7 Use of trusted/verified software modules 
and components (If available) 


C.4.5 


HR 


Available, and used 
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Table E,15 - Software design and development: 
software module testing and Sntegration (see 7.4.7 and 7.4.8 of lEC 61508-3) 



Technique/measure 


Ref 


SIL3 


Interpretation in this application 


1 Probabilistic testing 


C.5.1 


R 


Used for software modules wiiere no source code 
available and the definition of boundary values and 
equivalence classes for test data is difficult 


2 Dynamic analysis and testing 


B.6.5 
Table B.2 


HR 


Used for software modules where source code is 

availabie. 

Test cases from boundary value analysis, 

performance modelling, equivalence classes and 

input partitioning* structure-based testing 


3 Data recording and anaiysis 


C.5.2 


HR 


Records of test cases and results 


4 Functional and black-box testing 


B.5.1 

B.5.2 

Table B,3 


HR 


Used for software module testing where no source 
code is available and for integration testing^ 
Input data is selected to exercise all specified 
functional cases » including error handling. Test 
cases from cause consequence diagrams* 
prototyping, boundary value analysis, equivalence 
classes and input partitioning 


5 Performance modelling 


C.5.20 
Table B.6 


HR 


Used during integration testing on the target 
hardware 


6 Interlace testing 


C.5.3 


HR 


Not used 



Table EJ6 - Programmable electronics integration (hardware and software) 

(see 7.5 of lEC 61508-3) 



Technique/measure 



t Functional and black-box testing 



2 Performance modelling 



Ref 



8.5.1 

B.5.2 

Table B.3 



C.5.20 
Table B.6 



SO 

HR 



HR 



I nterpretation in this application 



Used as additional tests to software integration 
testing (see table E.fs) 

Input data is selected to exercise all specified 
functional cases, including error handling. Test 
cases from cause consequence diagrams, 
prototyping, boundary value analysis, equivalence 
classes and input partitioning 



Extensively used 



Table E.I 7 - Software safety validation (see 7.7 of lEC 61508-3) 



Technique/measure 



1 Probabilistic testing 

2 Simulation/modelling 



3 Functionai and bfack-box testing 



Ref 



C.5.1 



Table B.5 



B.5.t 

B.5.2 

Table B,3 



SIL3 



R 



HR 



HR 



jnterpretation in this application 



Not used for validation 

Finite state machines, performance modelling 
prototyping and animation 



Input data is selected to exercise all specified 
functional cases, including error handymg. Test 
cases from cause consequence diagrams 
boundary value analysis, and mpjit partitioning j 
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Table E.18 - Modification (see 7.8 of lEC 61508-3) 



Technique/measure 


Ref 


SIL3 


Interpretation in this application 


1 Impact analysis 


C.5.23 


HR 


Used 


2 Re-verify changed software module 


C.5.23 


HR 


Used 


3 Re-verify affected software modules 


C.5.23 


HR 


Used 


4 Revalidate complete system 


C.5.23 


HR 


Depends on the result of the impact analysis 


5 Software configuration management 


C.5.24 


HR 


Used 


6 Data recording and analysis 


0.5.2 


HR 


Used 



Table E.19 - Software verification (see 7.9 of lEC 61508-3) 



Technique/measure 



1 Forma! proof 



2. Probabilistic testing 



Ref 



C.5,13 



0,5.1 



SIL3 



Interpretation in this application 



Only exceptionally, for some very basic classes 
only 



Included in table E.15 



3 Static analysis 



B.6.4 
Table B.8 



HR 



For all newly developed code. 
Boundary value analysis, checklists, control flow 
analysis, data flow analysis, Fagan inspections, 
design reviews 



4 Dynamic analysis and testing 



B.6.5 
Table B.2 



HR 



Included in table E,15 



5 Software complexity metrics 



C.5. 1 4 R Used only marginally 



Software module testing and integration 



See table E.15 



Programmable electronics integration testing 



See table E.I 6 



Software system testing (validation) 



See table E. 17 



Table E.20 - Functional safety assessnnent (see clause 8 of [EC 61508-3) 



Assessment/technique 


Ref 


S1L3 


Interpretation in this application 


1 Checklists 


B.2.5 


R 


Used 


2 Decision/truth tables 


G.6.1 


R 


Used, to a limited degree 


3 Software complexity metrics 


C.5.14 


R 


Used only marginally 


4 - Failure analysis 


Table B.4 


HR 


Fault-tree analysis is extensively used, and 
cause consequerice diagrams are used to a 
limited degree 


5 Common cause failure analysis of diverse 
software (if diverse software is actually used) 


C.6.3 


HR 


Used 


6 Reliability block diagram 


C.6.5 


R 


Used 
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annex D). ^ 

1 
[10] Programmable efectronic systems in safety-related applications, Part 2: General technical 
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